Review the architecture skeleton before further buildout

The skeleton under packages/essapps (branch architecture-sketch) has outrun review. This issue lists what to review, ordered by leverage, so that review time goes where a wrong choice costs the most. Each item names the files and the question the review should answer. Notes and outcomes go into the handoff document at docs/developer/plans/review-handoff-2026-09-17.md, which is also what a fresh session gets together with the findings.

• The LoKI session notebook as a user story, packages/essapps/notebooks/loki-session.ipynb. Read as a user: submit, chain by reference, rerun with a slider, publish. Does any step feel wrong? A wrong step there is a design problem, not a code problem.
• The callable contract, packages/essapps/src/ess/apps/binding.py, warm.py, loki.py, and aggregation.py. This is what every workflow author writes against. Is resolve per parameter and stage_inputs how you would bind DREAM or BIFROST? Do contribute, combine, and finalize fit a combine you have written? Where should this contract live once it settles, essreduce next to the spec or essapps? Instrument packages cannot ship bindings until that is decided.
• Records and references, docs/developer/architecture.md, the section of that name plus "Changes needed in the workflow spec" (D13) and choice 3 (D8). Everything rests on it and the team stumbled on it once. Today's decision that a dataset reference is one identity string, encoded by the framework as pid:, run:, or path:, is new and in it.
• Rules, batches, and the trigger loop (D14), packages/essapps/src/ess/apps/rules.py and batch.py, and the "Rules" section of the sketch. Written from reading Mantid and FIA, not from running anything, so the highest chance of being wrong in a way tests cannot catch. Check the lookup and selector against how ISIS interfaces are used in practice, and whether apply, backlog, reprocess, and rerun are the operations a scientist would ask for.
• Combining (D15), the "Combining" section of the sketch and examples.py NORMALIZE. Is "contribution at the accumulation keys, normalisation after" right for powder and BIFROST, not only SANS?

Not worth review time now: the record store, data store, and launchers; they are mechanical and tested.

Decisions taken so far in this round: pandas stays a hard dependency; a dataset reference is a single string in the spec (scipp/ess#690) and the framework encodes its identities.

Work proceeding in parallel without review: the branch's edges vocabulary for the LoKI bins, serialize() carrying the D15 fields, the review deck refreshed to the current sketch, and an Amor reflectometry binding as a probe of collection outputs and a non-additive combine.