feat(specify): record in-context fork resolutions as auditable issue comments

The `spec-skeptic` `scope-fork` juror reads only the seeding issue plus
the spec. On the legitimate `specify` direct-entry path — a fork settled
in a long in-context design discussion — that resolution lives only in
ephemeral chat the juror cannot replay. When the issue body lags the
discussion (still lists the fork open), the juror correctly blocks, and
a design BLOCK escalates without self-correction. The result: auto-sign
was structurally almost unreachable for the in-context entry path.

Close the blind spot by giving the juror an auditable source instead of
weakening the gate. When `specify` enters in-context and a tracker issue
still lists a now-resolved fork as open, the orchestrator posts a
reconciliation comment recording each fork's resolution WITH provenance
(a record of the user's decision, never a fresh orchestrator one) before
writing the spec. The comment is persistent and audit-able — unlike a
carrier digest — so it, not the orchestrator's confidence, is what the
juror checks.

Separation of powers keeps it honest: the orchestrator writes the
comment, the adversarial juror enforces the provenance requirement. A
bare `decision: X` with no provenance does not resolve the fork — the
re-dispatched juror blocks on it. The escalation rule and the
three-field carrier are untouched; only the juror's information changes.

Mechanics:
- specify Step 1.5: reconciliation-comment sub-step, provenance format,
  issue-less fallback (auto-sign -> human sign-off, no weak spec-note).
- spec-skeptic: replace the "quoted in the dispatch" drift; juror reads
  the issue WITH comments via `issue_tracker.show_cmd`; provenance check.
- new profile slot `issue_tracker.show_cmd` (must render comments);
  documented in schema + template.
- issue skill: `tea issues <idx>` is body-only; `--comments` required
  (verified against tea 0.14.1 and Aura #55 — 180 vs 144 lines).
- consistency: design.md out-of-scope, README, pipeline.md, boss skill.

docs/design.md

@@ -113,8 +113,10 @@ The relationship:
 ## What's out of scope for this plugin
 
 - **Issue-tracker integration**: the plugin can read the
-  profile's `issue_tracker.kind` and `issue_tracker.list_cmd`
-  and invoke the configured listing command, but does not
-  directly call Gitea / GitHub / Linear APIs. The `boss` skill
-  uses the configured shell command for queue reads, so the
-  plugin remains transport-agnostic.
+  profile's `issue_tracker.kind`, `issue_tracker.list_cmd`, and
+  `issue_tracker.show_cmd` and invoke the configured listing /
+  single-issue commands, and `specify` may post a reconciliation
+  comment via the tracker's comment command — but the plugin does
+  not directly call Gitea / GitHub / Linear APIs. Every read and
+  write goes through the configured shell command, so the plugin
+  remains transport-agnostic.

docs/pipeline.md

@@ -113,7 +113,11 @@ signs. A `BLOCK` is never signed over: an editorial one (`criterion` /
 `ambiguity` / `plan-readiness`) is repaired in a bounded ≤ 2-round loop
 that re-runs the objective gates and re-dispatches all five lenses each
 round; a design one (`scope-fork` / `grounding`), an `INFRA_ERROR`, or
-an exhausted budget falls back to the human sign-off pause. See
+an exhausted budget falls back to the human sign-off pause. When the
+entry is in-context and the seeding issue still lists a now-resolved
+fork as open, `specify` posts a provenance-bearing reconciliation
+comment on the issue (Step 1.5) so the `scope-fork` juror can ratify the
+resolution instead of blocking on the stale body. See
 `../specify/SKILL.md` Step 6 and `../boss/SKILL.md` §"Spec auto-sign".
 
 ### planner

docs/profile-schema.md

@@ -173,6 +173,7 @@ authoritative semantics live at the `paths` row above.
 | `issue_tracker.close_marker` | string | `"closes #N"` | Marker the orchestrator includes in commit bodies to auto-close issues. |
 | `issue_tracker.url`          | string | (empty) | Human-browsable URL of the issue list — surfaced in notifications and cross-references. |
 | `issue_tracker.list_cmd`     | string | (empty) | Shell command that lists open issues. Used by the `boss` skill to read the forward queue. Examples: `tea issues ls --repo X/Y --state open`, `gh issue list --repo X/Y --state open`. |
+| `issue_tracker.show_cmd`     | string | (empty) | Shell command that renders **one** issue **with its comment thread**; the orchestrator and the `spec-skeptic` `scope-fork` juror append the issue index as the final argument (e.g. `tea issues --comments` → `tea issues --comments 55`). MUST include comments — a `specify` reconciliation comment (see `specify/SKILL.md` Step 1.5) is invisible to the juror otherwise. Examples: `tea issues --comments`, `gh issue view --comments`. If empty, the juror reads only the issue body and a fork resolved in-context but not echoed into the body cannot be ratified — auto-sign falls back to the human sign-off. |
 | `protected_branches`         | list | `[main]` | Branches that are sacrosanct in the same sense as main. |
 
 ## `notifications`