Seal the arms: schema, prompt and handler all obey the same one

Three places were leaking one arm's affordances into the other, so "the model
only sees one set of tools" was true of the tool list and false everywhere
else.

  EDIT SCOPE. `scope: {kind:"at"}` was on library_apply_text_ops in BOTH
  arms. Legacy is supposed to name an edit site by retyping document text;
  handing it structural addressing gave it the exact affordance the edit
  benchmark exists to measure. Gated.

  SYSTEM PROMPT. It told every non-coding session to "read only the needed
  span with library_read section=" -- a parameter the address arm does not
  have. The prompt is part of the surface; it now follows the arm.

  HANDLER. Schema gating alone is not isolation: the handlers still read
  args.section / args.page / args.pages whatever the arm, so a leaked
  parameter would have been honoured while the tool list looked clean. Each
  handler now reads only its own arm's vocabulary.

Also closed a hole Eli found by asking what read and find are for: `follow`
and `depth` expand an ADDRESS, not a search, so they belonged wherever `at`
does. They were on find and on edit scopes but not on read, for no reason
beyond the order I built things -- "read this clause and what it depends on"
was the one composition that could not be expressed. library_read now takes
them, sharing one budget across the seed and its neighbourhood so following
cannot multiply what a read costs.

Deduplication continued: `follow`/`depth` prose was written three times and
now sits once in library_outline beside the address grammar.

  nav cluster  legacy   700   address 1,341
  whole schema legacy 10,130  address 10,953

67 tests green across five suites, both arms.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9ToHYJVDxfeJcJwdzrP2H