Inspect saved entry failures from the xmd repl Sidekick #932

Story

As a person troubleshooting with the Sidekick in xmd repl, I want it to inspect an entry's saved source, outcome, and agent results through supported read-only operations, so it can explain a failure before proposing retries.

For example, an entry collects twelve ballots. Eight prompts complete; the ninth returns valid JSON but fails while saving its agent session. The Sidekick can distinguish the returned text from the failed execution and identify which work has no saved result without rerunning the entry. A missing result does not prove external work never started.

Current gap

REPL.EntryOutput reads rendered output. Empty or partial output does not show every saved prompt result or the underlying root error.

The evidence already exists in the execution journal. Today an investigator must find its host-specific filesystem path, parse JSONL, and reconstruct entry boundaries. Sidekick should not need that knowledge to troubleshoot its own REPL.

Accepted reads

Use the dotted API:

<REPL.Entry.Source entry={22} offset={0} limit={4096} />
<REPL.Entry.Prompt entry={22} prompt={9} field="reply" />
<REPL.Entry.Output entry={22} />
<REPL.Entry.Journal entry={22} offset={0} limit={20} />

Source reads the exact submitted document. Prompt reads a saved agent turn's
reply, request or error; reply is the default. Output reads rendered entry
output. Journal locates evidence through entry status, its saved failure,
completed/failed/cancelled prompt counts and a page of record metadata; use
Prompt to read the identified turn's text.

• Positive entry numbers are absolute and one-based. Omission or -1 selects
  the latest; -2 selects the previous entry. Prompt numbers follow the same
  convention within an entry, using canonical prompt order rather than
  asynchronous completion order.
• Resolve relative selectors once. Previous/next instructions pin the resolved
  positive entry and prompt numbers and preserve the selected field.
• Successful reads return structured JSON, capturable with ordinary
  as="name". They also provide designated feedback to Sidekick, with or
  without as. Only explicit <Output> renders chat text.
• Common pages contain entry identity, text or records, offset, total available
  length, requested limit, and complete previous/next call arguments or null.
  Prompt pages also identify the resolved prompt and field.
• Text positions count Unicode code points and default to 4096. Source and
  Prompt start at zero. Output defaults to the last 4096; explicit offset zero
  starts at the beginning, and negative offsets count from the end.
• Journal offsets count records, default to zero, accept negative offsets from
  the end, and default to 20 records. Record metadata identifies what ran,
  status and source position, plus the prompt number and agent where
  applicable. It does not include raw agent bodies, checkpoints, stacks or
  arbitrary result payloads.
• Limits can increase without an arbitrary hard maximum. Missing entry/prompt
  evidence is a refusal. An absent saved prompt error is text null, distinct
  from empty text.
• An unfinished entry exposes what is saved so far. Report running only while
  this REPL owns that work; after cold reopening, an entry without a final
  outcome is unfinished. Reading never waits for completion or resumes it.
• Journal's failure is the complete saved message or null. Shared yq in
  Add shared queries for XMD component values #934 selects it; there is no additional Journal field="error" option.
  Add <Slice> for bounded output excerpts #942's Slice explicitly bounds presentation without truncating the data.

Existing saved REPL.EntryOutput controls remain historical records of what
ran; inspection does not rewrite or re-evaluate them. Newly authored reads use
the accepted dotted names. Refresh available syntax through the existing
orientation-change behavior on the next explicit agent turn.

Contract

• Provide a read-only entry summary with exact admitted source, terminal status/root failure, and completed/failed prompt counts, separate from rendered output.
• Provide bounded, selectable access to that entry's saved agent results. Show status, returned text, and error separately, with source locations where available.
• Make the diagnostic operations discoverable through Guide.Recovery and the available syntax reference.
• An entry-failure receipt includes a usable instruction for inspecting that exact entry. It does not automatically return an unbounded trace, source dump, or every agent reply.
• Teach the evidence-first recovery process: inspect before retrying; preserve completed effects; distinguish returned content from successful execution; label hypotheses; read only the needed records.
• Inspection performs no agent call, entry execution, file mutation, or automatic retry. It observes only the selected entry in the current execution and preserves existing publication/secret protections.
• Large source, replies, and record collections have bounded reads with a discoverable way to continue.

Remaining planning decision

Before freezing #932's exact result shape, resolve the presented status question: should status consistently describe the entry, with a separate promptStatus for the selected saved turn, or should those statuses be nested? The flat status/promptStatus shape is the recommendation, not an accepted answer. The accepted member behavior above remains settled. This question does not block #940, #934 or #942.

The requested delivery chain is PR #943/#939 -> #940 -> #934 -> #942 -> #932. Each cluster uses its own worktree and REPL on the previous cluster's final signed, Architect/Planner-approved head. This is the chosen stack order, not a claim that every generic component inherently requires entry inspection.

Acceptance

• Diagnose the representative failure above from saved records without repeating any prompt or completed effect.
• A valid returned JSON object with a failed prompt status is reported as failed execution, not as a successfully accepted ballot.
• An entry with no rendered output can still expose its saved source and failure evidence.
• Large replies and many records stay within the requested bound, and continuation reads identify the same entry and records.
• A failure receipt points to the actual failed entry even while another entry is selected.
• An unfamiliar Sidekick discovers and uses the operation from the shipped guide and syntax reference without a filesystem-path hint.
• Cold inspection contacts no provider, changes no journal, and does not resume an interrupted suffix.

Use real saved-entry fixtures and the mounted Sidekick request/feedback path. Do not rely only on a JSON parser helper.

Relationships and scope

Follow-up to #883 and PR #921; supports #898's troubleshooting role and relates to Quest #827. This adds diagnostic access, not a prerequisite for the active Sidekick delivery.

The recommendations are recorded locally in xmd-troubleshooting-recommendations.txt in the PR2 worktree. The observed Entry 22 prompt-save failure is a separate defect; this story makes its evidence accessible rather than fixing ACPX persistence.

No generic filesystem access, arbitrary journal mutation, automatic recovery, full trace dump in every receipt, Parse behavior change (#922), or provider-session repair is included.