feat(specify): create a seeding issue for issue-less in-context auto-sign

Step 1.5's issue-less in-context case used to fall back unconditionally
to the human sign-off: with no tracker issue, the `scope-fork` juror had
no auditable source for an in-context fork resolution and (correctly)
blocked, so auto-sign was structurally unreachable on that path.

Close it the same way the lagging-issue case is closed — give the juror
an auditable artefact instead of weakening the gate. When the cycle has
no seeding issue, the orchestrator now creates one recording each
resolved fork WITH provenance (a record of the user's decision, never a
fresh orchestrator one). A new tracker issue is independent and
auditable — unlike the self-referential spec-note the old text rejected
— so it, not the orchestrator's confidence, is what the juror checks.
The provenance gate is unchanged: no real user statement is a Step-1.5
bounce, not a manufactured issue; the orchestrator writes, the juror
enforces.

Also thread a `seeding_issue` field through the scope-fork carrier so
the juror can actually find the issue to read (the lagging issue, the
newly created one, or `none`). Without it the juror had no issue index
and the record was invisible — a latent gap the lagging-issue path
shared.

- specify Step 1.5: issue-less branch creates a provenance-bearing
  seeding issue; body names the work (no forward ref to the unwritten
  spec); explicit create command; capture-the-index instruction.
- specify Step 6 + handoff table: seeding_issue carrier field.
- spec-skeptic: juror reads seeding_issue from the carrier; accepts
  provenance in a created issue's body, not only in a comment.
- consistency: README, pipeline.md, design.md.

docs/design.md

@@ -123,7 +123,7 @@ The relationship:
   issue-tracker commands (the repo slug, list command, and
   single-issue-with-comments command, all in its CLAUDE.md project
   facts) and invokes them, 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.
+  comment or create a seeding issue via the tracker's comment / create
+  commands — 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

@@ -114,10 +114,11 @@ signs. A `BLOCK` is never signed over: an editorial one (`criterion` /
 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. 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
+entry is in-context, `specify` gives the `scope-fork` juror an auditable
+source for an in-context fork resolution (Step 1.5) — a provenance-
+bearing reconciliation comment when a seeding issue lags the discussion,
+or a freshly created seeding issue when the cycle had none — so the
+juror can ratify the resolution instead of blocking for lack of one. See
 `../specify/SKILL.md` Step 6 and `../boss/SKILL.md` §"Spec auto-sign".
 
 ### planner