Fix The inbox takes 30-40 s

- inbox-gate-read-fast (step build/build): passed: attempt 2: verifier passed
  - attempt 1 builder, session 41d27a7d-b02f-47a6-8255-01a1b1fbd616: pass (said done)
  - attempt 1 verifier, session 2999b744-974f-4a03-8476-01a1b2156d6a: fail (verifier found 1 problem(s))
  - attempt 2 builder, session 1f2ecfde-ddc8-4101-b556-01a1b2289c99: pass (said done)
  - attempt 2 verifier, session d0c13c24-cfb6-4ddf-8efa-01a1b22d15e5: pass (Evidence written by the verifier)
  - attempt 1 finding f1: The acceptance requires the new budget test to assert that inboxGateQuestions folds each planned change set at most once; TestInboxGateQuestionsBudget (internal/api/inbox_gate_budget_test.go) asserts the statements, zero full-log decodes (countingCtx), the index catch-up and the 1 s budget, but nothing counts model folds per change set. Ran `go test -trimpath -count=1 ./internal/api -run Inbox -v`: all six inbox tests PASS, including TestInboxGateQuestionsBudget (wall time is spent waiting on the shared budget lock, about 19 s CPU). Removing both memos (the local modelOf map and ix.models in inbox.go) would still pass the test, since the per-question folds go through the index and decode no log. Add an assertion that each planned change set's model is built at most once per call: for example, check that len(ix.models) or a build counter equals the number of distinct change sets read (own plus 3 planned), or count index Entries/fold calls per change set.
- inbox-gate-questions-kept (step build/build): passed: attempt 1: verifier passed
  - attempt 1 builder, session 7beb197b-8ad6-45d7-9f51-01a1b215b0f3: pass (said done)
  - attempt 1 verifier, session 6386b61f-44e5-4c06-a675-01a1b2283b77: pass (Evidence written by the verifier)
- inbox-app-gate-scroll (step build/build): passed: attempt 1: verifier passed
  - attempt 1 builder, session ed118d91-6f8c-486e-b899-01a1b22d69cd: pass (said done)
  - attempt 1 verifier, session 52cc90d6-25fc-4d01-90a5-01a1b2317d28: pass (Evidence written by the verifier)
- inbox-gate-questions-kept (step review/review): open
  - attempt 2 fixer in cycle 2, session 37592deb-038c-4199-9fcf-01a1b2411808: pass (said done)
  - attempt 2 verifier in cycle 2, session a725333b-d883-4fb9-bb5f-01a1b242a029: pass (Evidence written by the verifier)
- inbox-app-gate-scroll (step review/review): open
  - attempt 2 fixer in cycle 2, session ff1856ca-7dd3-4be1-b09e-01a1b242e4cf: pass (said done)
  - attempt 2 verifier in cycle 2, session 867d575d-cae4-4f66-a891-01a1b24d1a9c: pass (Evidence written by the verifier)

## Checks

- compliance (step review/review): passed after 2 cycles
  - cycle 1: failed, check session 6d267582-1b76-44b3-9dce-01a1b233dc14 pass (said done), critic session c55be25c-2cf0-4835-b453-01a1b23f2abc pass (said done)
  - cycle 2: passed, check session 7960d6c6-375c-402a-a71c-01a1b253a0f7 pass (said done)
  - round 1 (cycle 1): 4 findings, 1 confirmed
    - f1 major at internal/api/inbox_gate_budget_test.go:146 on inbox-gate-questions-kept: Decision inbox-gate-questions-two-cases requires two Go test cases in internal/api; only case (a) (worktree does not read) exists. Case (b) — a worktree that reads, with one handle resolving in no planned change set, listing the unresolved handle with an empty statement and the resolved one with its full statement — has no Go test (the test's comment claims it, but the body only sets up kept-a/kept-b in an unreadable worktree; the verifier's evidence admits it was checked by hand only). — confirmed: Decision inbox-gate-questions-two-cases requires two Go cases in internal/api. Only TestInboxGateQuestionsKept (internal/api/inbox_gate_budget_test.go:150) exists, and it sets up a root with no .rhiza, so the worktree does not read and it covers case (a) only. No test in internal/api has a readable worktree where one stop-detail handle resolves in no planned change set and the resolved one keeps its statement (grep of internal/api/*_test.go finds none). The test's comment claims the unresolved-handle case, but the body does not set it up, and the verifier's evidence says it was checked by hand only. The leaf's own acceptance also names the unresolved handle, so it is not met as written.
    - f2 minor at internal/api/inbox_gate_budget_test.go:153 on inbox-gate-questions-kept: Case (a) asks that the run 'gets an inbox open item listing both handles ... and its answer action'; the test calls inboxGateQuestions directly and never checks the inbox open item or its action through the inbox op.
    - f3 minor at internal/tui/inboxapp/inboxapp_test.go on inbox-app-gate-scroll: Acceptance says 'a failed resume shows a detail panel that scrolls'; TestGateResumeFailureDetailScrolls only asserts the view is a ui.InfoPanel and never scrolls it (scrolling is covered for another kind by TestDetailPanelScrolls).
    - f4 nit at internal/api/inbox_gate_budget_test.go:103 on inbox-gate-read-fast: Acceptance says 'inbox returns every question'; the budget test exercises inboxGateQuestions, the function the inbox op uses, rather than the inbox op itself.
  - round 2 (cycle 2): 4 findings, 0 confirmed
    - f1 minor at internal/api/inbox_gate_budget_test.go:151 on inbox-gate-questions-kept: Case (a) asks that the run 'gets an inbox open item listing both stop-detail handles'; TestInboxGateQuestionsKept (and TestInboxGateQuestionsUnresolved for case b) call inboxGateQuestions directly and never go through the inbox op's open item. The cycle-1 major (no case b test) is fixed by TestInboxGateQuestionsUnresolved, which passes.
    - f2 minor at internal/tui/inboxapp/inboxapp_test.go:935 on inbox-app-gate-scroll: Acceptance says 'a failed resume shows a detail panel that scrolls'; TestGateResumeFailureDetailScrolls asserts only that the view is a ui.InfoPanel, never scrolls it (scrolling of that panel type is shown by TestDetailPanelScrolls).
    - f3 nit at internal/tui/inboxapp/inboxapp_test.go:863 on inbox-app-gate-scroll: Acceptance speaks of a gate item 'whose questions have empty statements' with the fallback 'above each TextArea'; the test makes only question 2 of 4 empty, so the fallback is shown for one TextArea, not several.
    - f4 nit at internal/api/inbox_gate_budget_test.go:103 on inbox-gate-read-fast: Acceptance says 'inbox returns every question'; the budget test times inboxGateQuestions, the function the inbox op uses, not the inbox op itself.
- quality (step review/review): passed after 1 cycle
  - cycle 1: passed, check session 3f5367a7-1690-4a0f-907a-01a1b23423b4 pass (said done)
  - round 1 (cycle 1): 5 findings, 0 confirmed
    - f1 minor at internal/api/inbox_gate_budget_test.go:147 on inbox-gate-questions-kept: TestInboxGateQuestionsKept's comment says it also covers a handle that resolves in no planned change set, but the test only uses a worktree with no .rhiza. The other path, where the worktree reads but a handle resolves nowhere (inboxGateRead keeps it with an empty statement), has no test.
    - f2 minor at internal/tui/inboxapp/inboxapp.go:858 on inbox-app-gate-scroll: The capability says the gate text scrolls with arrow keys as well as page keys and the wheel, but questionView only intercepts pgup/pgdown and the wheel; the arrow keys go to the TextArea. The code is reasonable (arrows belong to the TextArea), but the code and the statement disagree.
    - f3 minor at internal/tui/inboxapp/inboxapp.go:514 on inbox-app-gate-scroll: Model.View turns on cell-motion mouse mode for every view, including the list and the forms, so the whole app loses the terminal's native text selection (for example, copying a question's text). Only the scrolling views need it.
    - f4 nit at internal/api/inbox_gate_budget_test.go:30: quiettest.Wait's result is discarded with `_ = q`. The sibling budget tests pass q.String() to openTimingLog to record timings; either log the timings or drop the variable.
    - f5 nit at internal/api/inbox.go:1133: The local modelOf memo duplicates the writeIndex models memo that inboxGateRead has just enabled (ix.models). It is only useful in the no-index fallback, and no comment says so.
- qa (step review/review): passed after 2 cycles
  - cycle 1: failed, check session 8eebcc9a-d206-4eae-b21c-01a1b2349305 pass (said done), critic session e99ecaf8-46ef-4a65-84c6-01a1b23f80ba pass (said done)
  - cycle 2: passed, check session 9d02afc1-c4c3-451b-8c61-01a1b253fbf4 pass (said done)
  - round 1 (cycle 1): 3 findings, 1 confirmed
    - f1 major at internal/api/question.go:162 on inbox-app-gate-scroll: question.answer --run, which the Inbox app's gate submit calls once per question, still opens the run worktree with IndexPath cleared, so each answer decodes the full disk log: hands-on with the built binary in a clone of this repo (11,596 entries), one question answer --run took 36 s (profile: store.ReadLog 16.7 s, 67%), and submitting a four-question gate in rhiza tui app inbox froze the form for ~100 s with no feedback before the result showed. This is the same IndexPath="" cause the intent names, and the intent asks that the owner can answer the gate in the Inbox app and that the app stays well under 1 s; the fix this change set applies to inboxGateRead (index.DefaultPath of the worktree) applies here too. — confirmed: internal/api/question.go:162 (gateAnswerCtx) is untouched by this change set and still sets c.IndexPath = "" for the run worktree, so every question.answer --run reads and decodes the full disk log, and it also folds w.model(cs.ID) per planned change set with no memo: the exact cause the intent names, fixed only in inboxGateRead (inbox.go:1103). The intent requires the owner to answer each gate question in the Inbox app, and inbox-app-gate-scroll's submit calls question.answer --run once per question, so the new action pays tens of seconds per question with a frozen form. The same index.DefaultPath(worktree) + openWriteIndex approach applies here.
    - f2 minor at internal/api/inbox.go:1115 on inbox-gate-read-fast: inboxGateRead calls w.changeSets(), which decodes every change set's folded record from the index (writeIndex.changeSets -> Index.FoldedOf, ~0.76 s CPU of a 1.22 s profile). On the loaded VM (load 11-17, 4 cores) rhiza inbox at the gate took 1.1-1.7 s wall versus 0.4-0.75 s with no gated run; a 20x win over 26 s, but not 'well under 1 s' there.
    - f3 minor at internal/tui/inboxapp/inboxapp.go:855 on inbox-app-gate-scroll: The leaf says the question text scrolls with arrow and page keys and the wheel; in the gate form only pgup/pgdn and the wheel scroll it, arrow keys go to the focused TextArea (checked by hand). Reasonable for editing, but the statement and the footer differ.
  - round 2 (cycle 2): 1 finding, 0 confirmed
    - f1 minor at internal/api/inbox.go:1115 on inbox-gate-read-fast: Still as in cycle 1's f2: on the loaded VM (load 14, 4 cores) rhiza inbox at a gate took 2.1 s wall (1.0 s user CPU) in a clone of this repo; inboxGateRead's w.changeSets() decodes every folded change set from the index. A >10x win over the 26-36 s before, but not 'well under 1 s' under that load.
- scope (step review/review): passed after 1 cycle
  - cycle 1: passed, check session 1d034b87-79f2-4fc3-99cc-01a1b234e7bd pass (said done)
  - round 1 (cycle 1): no findings
- model (step review/review): passed after 2 cycles
  - cycle 1: failed, check session 2430ac96-1875-4a57-b83a-01a1b2354e7a pass (said done), critic session ddaf6ee5-b84e-47c1-9153-01a1b23fc8e0 pass (said done)
  - cycle 2: passed, check session a5699a19-3887-4d8f-aac5-01a1b2544e44 pass (said done)
  - round 1 (cycle 1): 2 findings, 1 confirmed
    - f1 major at internal/api/inbox_gate_budget_test.go:147 on inbox-gate-questions-kept: The model settles this leaf's acceptance in Decision inbox-gate-questions-two-cases (answering review-01m6rxk0-r3-f1): two Go test cases, (a) the worktree does not read, so both handles are listed with empty statements, and (b) the worktree reads but one handle resolves in no planned change set, so that one has an empty statement and the resolved one keeps its full statement. The code has only case (a), TestInboxGateQuestionsKept. Its doc comment also claims 'one whose handle resolves nowhere', which the test never sets up. The verifier's evidence admits case (b) was checked by hand only. Add the case (b) test, which covers the per-handle fallback in inboxGateRead (inbox.go, the loop that leaves q.Statement empty when no planned change set resolves h), and fix the comment. The leaf's acceptance field also still holds the old combined wording the decision replaced. — confirmed: Decision inbox-gate-questions-two-cases (log 01M6RYN6555V24K2K9ZGEXTEBX) settles the leaf's acceptance as two Go test cases in internal/api. The diff adds only TestInboxGateQuestionsKept (internal/api/inbox_gate_budget_test.go:147), which sets up case (a) alone: a root with no .rhiza and handles kept-a, kept-b. No test anywhere in internal/api or the inbox-gate testscripts sets up case (b), a readable worktree with one handle resolving in no planned change set, so the per-handle fallback in inboxGateRead (the loop that leaves q.Statement empty) is untested. The doc comment's 'one whose handle resolves nowhere' describes a setup the test never builds.
    - f2 minor at internal/tui/inboxapp/inboxapp.go:855 on inbox-app-gate-scroll: The leaf statement says the gate form's question text scrolls with 'arrow and page keys and the mouse wheel'. questionView.Update only scrolls the text on pgup/pgdown and the wheel; arrow keys go to the Form/TextArea. The acceptance names only page-down and the wheel, so either drop 'arrow' from the statement or note that arrows move within the TextArea.
  - round 2 (cycle 2): 2 findings, 0 confirmed
    - f1 minor at internal/api/question.go:172 on inbox-gate-read-fast: The fixer's commit 3c0b06a0 makes gateAnswerCtx (question.answer --run, which the Inbox app's gate submit calls once per question) read and write through the run worktree's own index, guarded by TestGateAnswerUsesWorktreeIndex. No leaf states this: inbox-gate-read-fast names inboxGateQuestions and the inbox reads only. Its statement could name the gate answer path too, so the model records that answering at a gate also never decodes the full log.
    - f2 minor at internal/tui/inboxapp/inboxapp.go:855 on inbox-app-gate-scroll: Still open from cycle 1: the statement says the gate question text scrolls with 'arrow and page keys and the mouse wheel', but in the gate form only pgup/pgdn and the wheel scroll it; arrows go to the focused TextArea (the QA evidence confirms this). The statement should drop 'arrow' for the gate form, or say that arrows edit the TextArea.

## Code checks

- step review/code: pass

## Sign-offs

- signoff (visit 1): approved by rule autonomous

## Sessions

- build/build, session 41d27a7d-b02f-47a6-8255-01a1b1fbd616: tokens input 46, output 9884, cache creation 62722, cache read 1607567; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 2999b744-974f-4a03-8476-01a1b2156d6a: tokens input 24, output 5519, cache creation 39950, cache read 691380; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 7beb197b-8ad6-45d7-9f51-01a1b215b0f3: tokens input 24, output 4393, cache creation 36634, cache read 661978; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 6386b61f-44e5-4c06-a675-01a1b2283b77: tokens input 24, output 6479, cache creation 35849, cache read 659869; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 1f2ecfde-ddc8-4101-b556-01a1b2289c99: tokens input 20, output 3668, cache creation 35934, cache read 558017; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session d0c13c24-cfb6-4ddf-8efa-01a1b22d15e5: tokens input 18, output 2812, cache creation 32473, cache read 479265; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session ed118d91-6f8c-486e-b899-01a1b22d69cd: tokens input 38, output 13392, cache creation 65348, cache read 1346323; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 52cc90d6-25fc-4d01-90a5-01a1b2317d28: tokens input 14, output 3338, cache creation 31981, cache read 364024; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 6d267582-1b76-44b3-9dce-01a1b233dc14: tokens input 22, output 3604, cache creation 47771, cache read 660966; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 3f5367a7-1690-4a0f-907a-01a1b23423b4: tokens input 20, output 4735, cache creation 46472, cache read 633663; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 8eebcc9a-d206-4eae-b21c-01a1b2349305: tokens input 70, output 18276, cache creation 72647, cache read 2828802; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 1d034b87-79f2-4fc3-99cc-01a1b234e7bd: tokens input 16, output 2524, cache creation 41375, cache read 446904; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 2430ac96-1875-4a57-b83a-01a1b2354e7a: tokens input 22, output 3989, cache creation 47161, cache read 713122; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session c55be25c-2cf0-4835-b453-01a1b23f2abc: tokens input 14, output 2052, cache creation 28314, cache read 345302; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session e99ecaf8-46ef-4a65-84c6-01a1b23f80ba: tokens input 14, output 1991, cache creation 31999, cache read 353631; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session ddaf6ee5-b84e-47c1-9153-01a1b23fc8e0: tokens input 16, output 2324, cache creation 28548, cache read 395788; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 37592deb-038c-4199-9fcf-01a1b2411808: tokens input 22, output 4248, cache creation 35271, cache read 615365; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session a725333b-d883-4fb9-bb5f-01a1b242a029: tokens input 14, output 2444, cache creation 29934, cache read 353320; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session ff1856ca-7dd3-4be1-b09e-01a1b242e4cf: tokens input 48, output 7792, cache creation 54092, cache read 1566165; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 867d575d-cae4-4f66-a891-01a1b24d1a9c: tokens input 24, output 3393, cache creation 37097, cache read 671122; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 7960d6c6-375c-402a-a71c-01a1b253a0f7: tokens input 20, output 2991, cache creation 50176, cache read 643810; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 9d02afc1-c4c3-451b-8c61-01a1b253fbf4: tokens input 46, output 12737, cache creation 69724, cache read 1850332; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session a5699a19-3887-4d8f-aac5-01a1b2544e44: tokens input 18, output 2939, cache creation 54400, cache read 605863; helper tokens input 0, output 0, cache creation 0, cache read 0

Totals: tokens input 594, output 125524, cache creation 1015872, cache read 19052578; helper tokens input 0, output 0, cache creation 0, cache read 0