v0.80.0

Security

• The search walk was unprotected wherever the file-read cage could
  not be installed. ADR-0086 §5 said the file tools fall back to
  in-process reads "with risk.credentialRead as the boundary", but
  that function judges a path ARGUMENT and search_files has none: it
  is not in the credential read set, its verdict is Safe, and it
  never reaches a gate. So on a machine where the startup probe failed,
  the walk opened .env and printed the matching lines to the model
  with nothing in between — weaker than 0.78.0, which withheld the
  entry and reported a count — while the degradation note told the
  operator that credential files still needed their approval.
  readForSearch now refuses a path on the one internal/sandbox list
  before it opens the file, returning the permission error the walk
  already reports, so a refused file lands in the same
  [not read: … ] footer whether the kernel refused it or this check
  did. The refusal is unconditional rather than switched on the cage's
  absence: a mode branch would put the safety on the path that is
  exercised least, which is how this shipped. Inside the child the
  kernel still refuses whatever the check misses, so the list stays the
  fast path and not the boundary. Regression test:
  TestSearchFilesRefusesCredentialsWithoutTheCage drives a registry
  with no file child — the degraded path exactly — and fails on the
  leaked line without the guard. ADR-0086 carries an Amended note.

• "One function, applied at every spawn site" was a claim, not a
  mechanism (ADR-0087 §2). Four kinds of child did not apply it: the
  unconfined shell (--no-sandbox), the startup lane probes, the
  sandbox availability probe and the clipboard capture. Only the first
  carried real exposure — it built its command with no environment at
  all, so the child inherited the parent's whole environment including
  gem-agent's own configuration variables. The other three read nothing in the runtime's
  namespace, so what was exposed there was the sentence rather than a
  secret. All four apply the rule now, and
  the read lane's probe extends the filtered environment with its
  temporary directory instead of rebuilding it from the parent's — an
  overwrite that would have quietly undone the fix.

• The class is closed by a test.
  TestEverySpawnSiteAppliesTheChildEnvRule fails when a function
  builds an exec.Cmd without naming the helper that applies the
  environment rule. The partition test next door pins the two NAME
  lists and cannot see a call site, which is why a false sentence
  survived a green build. ADR-0087 carries an Amended note.

  Found writing the second revision of the architecture review,
  recorded there as R33.

Fixed

• The degradation note and the /settings row claimed something that
  was not true of the walk. Both said credential files "ask you"
  when the cage is absent; a search skips the file and names it, it
  does not ask. They now say credential files are refused either way,
  and by whom.

• Text that outlived the credential redesign. search_files'
  description said a file "the sandbox would not let this tool read" is
  named rather than hidden; now that the walk carries its own refusal
  that sentence is true of either enforcer, so it says a file this tool
  may not read. The profile's own doc comment claimed stat .env is
  refused — it is not, and never was under the shipped deny: that
  measurement is left over from the file-read* cut that broke every
  directory walk, which 0.79.0 fixed and recorded two bullets later.
  The 0.79.0 entry now carries an inline correction rather than a
  rewrite. ADR-0086 and ADR-0087 name the version that shipped them
  instead of saying "implemented and unreleased".

• A product rule, in AGENTS.md. A defect or design change in a
  mechanism both runtimes have is fixed in both, in the same piece of
  work. This file had not mentioned the sibling runtime at all, and the
  sibling's list_files and list_tree were still telling the model
  that credential files are withheld from listings — a release after
  ADR-0086 §3 withdrew that here. A shared mechanism fixed in one place
  is not fixed.