Tracking: adopt zcode-core ideas researched from the desktop app

Background

I reverse-engineered the ZCode desktop app and the zcode.cjs core it ships. The full write-ups live in the private zcode-article repo (not published):

• zcode-anatomy.md - binary layout and the extraction pipeline
• ui-core-interaction.md - the UI-to-core pipeline and the fork bridge comparison
• zcode-core-internals.md - the runtime stack, the agent loop, and the goal machine

This issue tracks what to work on next, taken from the "adoptable pieces" sections of that research. (Repo issues were enabled for this.)

Goal-system items (ext/goal)

• #11 - verify completion with a tool-less judge call instead of model self-report
• #13 - stop continuing when there is no actionable next step
• #15 - pause the active goal on user interrupt
• #17 - per-iteration accounting and timeline markers
• #19 - inject status changes at turn-safe points (reminder deferral)

Bridge items (core/src/client.rs)

• #21 - stall timeout on the stream-json pipe plus staged process-tree teardown
• #23 - experiment: keep one core warm across turns of a thread
• #25 - permission mirroring via interaction/* callbacks to replace --mode yolo (depends on #23)
• #27 - compat retry ladder for zcode.cjs version drift

Suggested order

1. #15 and #13 - small, independent ext/goal wins
2. #11 - bigger; changes goal completion semantics, needs an integration test
3. #21 - bridge robustness, independent of goals
4. #23 - the experiment that informs #25
5. #17 and #19 - polish once 1-3 land
6. #25 and #27 - exploratory / defensive

This is a tracking issue rather than a single task, with work split between ext/goal and core/src/client.rs. Start with the suggested first items, #15 or #13, and read their individual issue descriptions; the private research write-ups are not available here. Done means selecting one tracked item and completing its separate implementation and validation work.