flatpak: inside the sandbox /usr is the Sdk's, the host's at /run/host/usr

Inside the Flatpak the lenses see the host's filesystem with its /usr at
/run/host/usr - the sandbox's own /usr is the Sdk's - but not the user
and system Flatpak installations (~/.local/share/flatpak is empty inside,
/var/lib/flatpak absent), so a repository whose dependencies live in one
points its lens sections at the host's copies.
The commit-range lenses' common text (_common-repo.md) tells them where
the host's /usr is, a fact of the Flatpak rather than one repository's
convention; the kernel modes' _common.md, which says nothing of files
outside the working directory or of /usr, keeps the Python driver's
bytes. The README's sandbox notes name it, and the goldens' system text
follows.

process/lenses/_common-repo.md

@@ -7,7 +7,7 @@ Ground rules, all of them load-bearing:
 - Do NOT read `.review-gates/push/` (the frozen artifacts, dumps, manifests, gate-state of this and earlier reviews), the pipeline's own directory, or anything about how this artifact was produced; when INPUTS names a ledger and evidence paths, those are the only review records you may read. Adversarial independence is the point.
 - "Send" in the verdict vocabulary means the push: SEND-READY = this range may be pushed as far as your lens is concerned; a `send-time-check` note is a check to make at push time.
 - You never modify files or the repository. A lens whose prompt carries an APPLICATION UNDER TEST block acts in that application, through its browser, on a throwaway local stack - and only there; a lens whose prompt carries a DATABASE UNDER TEST block runs SQL in that database, in transactions the pipeline rolls back - and only there. Anything you cannot check becomes a note (kind=info, unverified or send-time-check) with what would settle it - never silence.
-- Tool permissions are an ALLOWLIST and nobody can approve anything else - a denied call wastes a turn and performs nothing. Allowed for every lens: Read, Glob, Grep; Bash with `git -C <tree> <read-only subcommand>` (diff log show grep blame ls-tree ls-files cat-file rev-parse rev-list hash-object describe merge-base name-rev shortlog for-each-ref branch tag status worktree remote), cat, rg, grep, wc, head, tail, `sed -n`, ls, find, diff, sha256sum, sort, uniq, cut, awk, echo, printf, cd, and `python3 -c` / `python3 -` heredocs. A lens with an APPLICATION UNDER TEST block also has the browser tools (mcp__playwright__*), `curl` against the local origins that block names, and the exact one-time-code command it prints; a lens with a DATABASE UNDER TEST block also has the exact SQL command that block prints. No build tool, no test runner, no package manager, no compiler, no stack commands: proofs are constructed against the source and, for the functional lens, observed in the application - with a DATABASE UNDER TEST block a proof may also be run in that database; existing tests are evidence to read. Compound commands are checked part by part; shell loops, subshells, `$` expansions and anything that writes, mails, connects elsewhere or builds are denied. Files outside the working directory (a system library under /usr, an installed package) are readable with the Read tool only; a Bash command naming such a path is denied.
+- Tool permissions are an ALLOWLIST and nobody can approve anything else - a denied call wastes a turn and performs nothing. Allowed for every lens: Read, Glob, Grep; Bash with `git -C <tree> <read-only subcommand>` (diff log show grep blame ls-tree ls-files cat-file rev-parse rev-list hash-object describe merge-base name-rev shortlog for-each-ref branch tag status worktree remote), cat, rg, grep, wc, head, tail, `sed -n`, ls, find, diff, sha256sum, sort, uniq, cut, awk, echo, printf, cd, and `python3 -c` / `python3 -` heredocs. A lens with an APPLICATION UNDER TEST block also has the browser tools (mcp__playwright__*), `curl` against the local origins that block names, and the exact one-time-code command it prints; a lens with a DATABASE UNDER TEST block also has the exact SQL command that block prints. No build tool, no test runner, no package manager, no compiler, no stack commands: proofs are constructed against the source and, for the functional lens, observed in the application - with a DATABASE UNDER TEST block a proof may also be run in that database; existing tests are evidence to read. Compound commands are checked part by part; shell loops, subshells, `$` expansions and anything that writes, mails, connects elsewhere or builds are denied. Files outside the working directory (a system library under /usr, an installed package) are readable with the Read tool only; a Bash command naming such a path is denied. Inside the Flatpak (`FLATPAK_ID` is set) `/usr` is the Sdk's: the host's `/usr`, the one a native build of the repository compiles against, is at `/run/host/usr`, and the user and system Flatpak installations (`~/.local/share/flatpak`, `/var/lib/flatpak`) are not visible.
 - Turn budget: every tool call is a turn and the budget is small. Batch independent reads and stop in time to return the structured output. A pass that runs out of turns returns nothing and the lens is marked NOT RETURNED.
 
 Verdict rules (process/prepush.md §Verdicts): findings are defects by your lens's charter question (objective wrongness); every finding blocks unless dischargedBy names an id listed under DISPOSITIONS IN FORCE. Everything that is not a defect but carries an action or a record-worthy fact is a note, never a finding; an item you judged below the bar is an immaterial note with its reason. Do not grade findings. Every finding and note carries evidence (file:line, a verbatim quote, the steps taken and a screenshot path). The verdict field is FIX FIRST iff any finding is undischarged - the pipeline derives the same and fails closed on disagreement.