The app hands its log to Dev Updater on the phone, not through ai-server

Iris's call once the upload route was working: put it in Dev Updater
properly. So the app now exposes its own ring through a ContentProvider
at `<applicationId>.devlog` -- Dev Updater's contract, written down in
that project's README, not something invented here -- and Dev Updater's
phone app reads it on the same device and forwards it to its own build
machine. No tunnel, no token, no second enrolment, and any app that
server delivers can implement the same and get the same Runtime tab.

`DevLogProvider.java` plus `devlog.rs` are the platform glue only: a flat
`String[]` across JNI, a `MatrixCursor` on the Java side, and
`nativeReady` telling Rust the authority the provider actually
registered, so the Diagnostics pane can name somewhere a reader can
query rather than composing a guess. `LogRing::newest_seq()` is the one
addition in `client-core`: an in-memory ring starts again at zero, so it
is what lets a reader notice the process restarted instead of silently
skipping everything since.

Deleted with it, so there is one mechanism: `client_core::log_upload`,
`POST /client-log` on ai-server, the `AI_APP_LOG_*` baking (which left
`build.rs` with nothing to do), and the uploader on both Android
clients. Kept: the ring, `RingLogger`, `install_process_logger`, and the
Diagnostics line -- whose second half is now `devlog provider:
content://<authority>`.

Verified end to end on this checkout's emulator: iris's own
`iris::android::view` startup lines read out of the provider by the
shell, forwarded by Dev Updater's Runtime tab, and served back from
`GET /apps/android-app/components/app/logs?kind=runtime`. A component
whose package has no provider says so in as many words.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

client-core/src/log_ring.rs

@@ -11,10 +11,12 @@
 //!
 //! Two consumers, both reading the same ring rather than each keeping
 //! their own: the bench app's `Copy report`/`Diagnostics` (which reads
-//! [`LogRing::to_text`] and [`LogRing::summary`]) and the uploader in
-//! [`crate::log_upload`] (which reads [`LogRing::since`]). That is why
-//! reading does not consume: a line the uploader has sent must still be in
-//! the report, and a report taken twice must say the same thing.
+//! [`LogRing::to_text`] and [`LogRing::summary`]) and whatever hands the
+//! log out of the process -- on Android, the `DevLogProvider` Dev Updater
+//! queries, which reads [`LogRing::since`] and [`LogRing::newest_seq`].
+//! That is why reading does not consume: a line already handed over must
+//! still be in the report, and a report taken twice must say the same
+//! thing.
 
 use std::collections::VecDeque;
 use std::sync::{Arc, Mutex, OnceLock};
@@ -207,6 +209,21 @@ impl LogRing {
         self.with(|inner| inner.dropped)
     }
 
+    /// The sequence number of the newest line held, or `None` for a ring
+    /// nothing has been written to.
+    ///
+    /// What a reader needs to notice that this process **restarted**: the
+    /// ring is in memory, so a new process starts again at zero, and a
+    /// reader holding a cursor from the previous one would otherwise ask
+    /// for lines after a number nothing will reach for hours and see
+    /// nothing at all -- silently, which is worse than seeing the log
+    /// begin again. Answering `None` rather than 0 for an empty ring is
+    /// the same distinction [`Self::summary`] draws: "nothing has been
+    /// logged" is not a sequence number.
+    pub fn newest_seq(&self) -> Option<u64> {
+        self.with(|inner| inner.lines.back().map(|line| line.seq))
+    }
+
     /// When the newest line was written, in unix milliseconds, or `None`
     /// for a ring nothing has been written to.
     pub fn last_at_ms(&self) -> Option<u64> {
@@ -426,6 +443,24 @@ mod tests {
         assert_eq!(cursor, 4);
     }
 
+    /// The restart signal: a reader that saw sequence 4 and is now told
+    /// the newest is 0 knows the process is not the one it was reading.
+    #[test]
+    fn the_newest_sequence_says_where_the_ring_is_and_nothing_for_an_empty_one() {
+        let ring = LogRing::new(100, 1 << 20);
+        assert_eq!(ring.newest_seq(), None, "an empty ring has no newest line");
+        fill(&ring, 5);
+        assert_eq!(ring.newest_seq(), Some(4));
+
+        let restarted = LogRing::new(100, 1 << 20);
+        fill(&restarted, 1);
+        assert_eq!(
+            restarted.newest_seq(),
+            Some(0),
+            "a fresh ring starts again, which is exactly what a reader has to notice"
+        );
+    }
+
     #[test]
     fn reading_does_not_consume() {
         let ring = LogRing::new(100, 1 << 20);