I read this as a read-only root-cause investigation - I’ll trace the launcher’s bubblewrap mounts and authority lock initialization, then return exactly three ranked causes with distinguishing evidence and minimal fixes.


I read this as root-cause triage - here are exactly three ranked causes with distinguishing evidence and minimal fixes.

1. **Launcher omitted the external authority writable mounts — direct cause.**
   **Evidence:** `--ro-bind / /` covers `/home/cube/.hermes/runtime-authority/...`; the only writable binds are profile, systemd-user, and migration. The failing lock is therefore read-only inside bwrap despite host ext4 being writable.
   **Minimal fix:** writable-bind the exact sealed authority root and its credential directory, not the broad Hermes tree.

2. **Authority loading unexpectedly performs a write.**
   **Evidence:** `RuntimeAuthoritySource.__init__` unconditionally calls `self.lock_path.chmod(0o600)`, although the existing lock is already `0600`. `authorize()` also opens it with `"r+"` despite only taking a shared flock.
   **Minimal fix:** validate the existing mode and open the shared lock read-only. This removes needless writes during loading, but the transaction still needs cause #1’s mount because promotion and rollback genuinely mutate authority state.

3. **Tests/rehearsal never reproduced the live mount topology.**
   **Evidence:** the launcher test merely asserts that some `--bind` exists; disposable authority tests use writable `tmp_path` storage. The passing 13-case rehearsal therefore did not exercise an external authority beneath the root read-only bind.
   **Minimal fix:** add one exact-bwrap integration test with authority outside the three existing writable roots, asserting the real worker reaches authorization and that only the explicitly bound authority paths are writable.