=== J-crashsafe  attempts=1 quota_waits=0 hard_fails=0 ===
cost=$4.0241814 turns=111 err=?
--- result (tail) ---
tingsStore.setLastShelfId`. A Room/disk failure during *save* (as opposed to *lookup*) can still crash the process. The task scoped this fix to the lookup path specifically ("Note that `bookRepository.findByIsbn13(isbn13)` is inside this function too... This is deliberately belt-and-braces with §1"), so I left `performSave` alone rather than expanding scope unasked — but it's the same failure class and worth a future wave if it matters.

**What I could not do / did differently**

- Switched `LocalClipboardManager`/`AnnotatedString` to the non-deprecated `LocalClipboard`/`ClipEntry` API for the Copy action, since the deprecated path threw a fresh compiler warning on a file I was actively touching (instructions call out exactly this class of warning as not-cosmetic). Small deviation from the most obvious implementation, done to avoid leaving a new warning behind.
- No new dependencies needed; nothing in `build.gradle.kts` or `libs.versions.toml` touched.
- Did not touch `data/local`, `data/remote`, `data/repo`, `data/prefs`, or `server/`. `AppContainer.kt`/`BookshelfApplication.kt` edits are exactly the `crashReporter` wiring §3 needs.

**Anything I noticed that looks wrong but is out of scope**

- As noted above, `performSave`/`performSaveManualEntry` (the *save* path, not lookup) has the same unguarded-Room-call shape that `runLookup` had before this fix. Same failure class, different function.
- `ScanViewModel.manualIsbnEntered` and `retryLookup` both do `viewModelScope.launch { onScanned(...) / runLookup(...) }` — fire-and-forget launches. Since `runLookup` no longer lets anything but `CancellationException` escape, and `viewModelScope` cancellation is exactly what should happen there, this is fine as-is; flagging only because it's adjacent code I read closely.