iris: a device change re-uploads its textures, and a mark is one texture per shape

The bench APK panicked on frame 1 on the emulator:

    iris panic at iris/core/src/render/texture.rs:461:22:
    texture slot 89 is not a live standalone image: None

widget::mark called Textures::add per widget, so a folded card per tool
call meant a standalone image, a bind group and a draw call each --
hundreds of copies of three pictures. Textures::reset, which the Android
surface-rebuild path calls for a genuinely new renderer, then threw the
slot numbering away with the pixels, leaving every one of those live
handles naming a slot nothing recognised. Its doc had said the only
standalone image in the workspace was tabs-ui's, "confirmed by grep" --
true when written, false the moment mark existed.

Textures::reupload replaces reset: queue every slot for upload again in
slot order, empty slots included, so the new device gets the same slot
numbering and a handle a widget has been holding still names its own
texture. The glyph atlas is no longer cleared on that path either, so an
app switch stops re-rasterising every glyph on screen.

Textures::shared(key, make) is one texture per description, keyed by a
SharedTextureKey the caller packs exactly rather than hashes. mark keys on
direction and colour: three mark textures for the screen, not one a card.

And the devlog can finally show a panic. After a crash, Dev Updater's
query starts the app process for the provider alone, so no activity ran,
so set_crash_dir never replayed the panic hook's file -- the Runtime tab
held one line, the provider announcing itself. DevLogProvider.nativeReady
takes the files directory and does the replay from onCreate; the hook also
saves the dying run's last 80 lines beside the panic, read through a new
non-blocking LogRing::try_tail_text so a panic holding the ring's lock
cannot deadlock the hook.

Verified on this checkout's emulator: opens clean, survives 33 full-screen
scrolls back through the fixture, image_bind_group_creates_prev=1; a real
panic replays into the next launch, and a hand-written last-panic.txt
replays in a process started by a provider query with no activity.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

client-core/src/log_ring.rs

@@ -278,6 +278,37 @@ impl LogRing {
         format!("{omitted} earlier lines omitted; full log in Dev Updater's Runtime tab\n{tail}")
     }
 
+    /// The newest `max_lines` lines, formatted, or `None` if the ring is
+    /// locked at this instant.
+    ///
+    /// For the one caller that must not block: **the panic hook**. A panic
+    /// raised while this ring's own lock was held -- an allocation failing
+    /// inside [`Self::push`], an assertion in a `log::Log` on the way here
+    /// -- would deadlock the hook against the thread that is panicking,
+    /// and the process would hang instead of aborting, with nothing
+    /// written anywhere. Losing the context lines is the right trade
+    /// against that, and `None` says which happened rather than looking
+    /// like an empty log.
+    pub fn try_tail_text(&self, max_lines: usize) -> Option<String> {
+        let guard = match self.0.try_lock() {
+            Ok(guard) => guard,
+            // A poisoned lock is uncontended, so its contents are still
+            // readable -- the same judgement as `with`.
+            Err(std::sync::TryLockError::Poisoned(poisoned)) => poisoned.into_inner(),
+            Err(std::sync::TryLockError::WouldBlock) => return None,
+        };
+        let lines = &guard.lines;
+        let from = lines.len().saturating_sub(max_lines);
+        Some(
+            lines
+                .iter()
+                .skip(from)
+                .map(LogLine::format)
+                .collect::<Vec<_>>()
+                .join("\n"),
+        )
+    }
+
     /// One line for a diagnostics pane: how much is held, how much was
     /// dropped, and when the last line arrived. "no lines yet" is its own
     /// wording rather than a count of zero with a made-up time, because
@@ -587,6 +618,30 @@ mod tests {
         assert!(rest.last().unwrap().ends_with("line 199"));
     }
 
+    #[test]
+    fn try_tail_text_gives_the_newest_lines_with_no_header() {
+        let ring = LogRing::new(1000, 1 << 20);
+        fill(&ring, 200);
+        let tail = ring.try_tail_text(80).expect("nothing holds the lock");
+        let lines: Vec<&str> = tail.lines().collect();
+        assert_eq!(lines.len(), 80, "the cap, and no header: this is a file");
+        assert!(lines[0].ends_with("line 120"), "{}", lines[0]);
+        assert!(lines[79].ends_with("line 199"), "{}", lines[79]);
+    }
+
+    /// The whole point of the `try_`: the panic hook calls this from a
+    /// thread that may already hold the ring's lock, and a blocking read
+    /// there would hang the process instead of aborting it.
+    #[test]
+    fn try_tail_text_answers_none_rather_than_blocking_on_a_held_lock() {
+        let ring = LogRing::new(10, 1 << 20);
+        fill(&ring, 3);
+        let held = ring.0.lock().expect("fresh ring");
+        assert_eq!(ring.try_tail_text(80), None);
+        drop(held);
+        assert!(ring.try_tail_text(80).is_some());
+    }
+
     #[test]
     fn an_empty_ring_says_so_rather_than_reporting_a_time() {
         let ring = LogRing::with_defaults();