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.

boss/SKILL.md

@@ -366,12 +366,17 @@ and defined there. The boss-side contract is just this:
   question in the user's place; the full re-panel each round is what
   stops an editorial repair from laundering one in. The gate owns this
   loop (`../specify/SKILL.md` Step 6) — boss only enforces the notify.
-  One upstream detail matters here: when a fork was settled in-context
-  but the seeding issue still lists it open, `specify` Step 1.5 posts a
-  provenance-bearing reconciliation comment on the issue so the
-  `scope-fork` juror ratifies the resolution from an auditable source
-  rather than false-blocking on the stale body. That comment records a
-  *user* decision; it never lets the orchestrator certify its own.
+  One upstream detail matters here: a fork settled in-context may be
+  invisible to the `scope-fork` juror, which reads the seeding issue.
+  `specify` Step 1.5 gives it an auditable source either way — when a
+  seeding issue exists but still lists the fork open, it posts a
+  provenance-bearing reconciliation comment; when there is *no* seeding
+  issue (design settled in pure chat), it creates one that records the
+  resolution with provenance and becomes the cycle's seeding issue.
+  Both record a *user* decision; neither lets the orchestrator certify
+  its own — no real user statement is a Step-1.5 bounce, not an artefact
+  to manufacture. The orchestrator writes the record; the juror checks
+  the provenance.
 - **On a clean sign, do not stop.** Commit the spec (the auto-sign
   commit subject carries `(boss-signed)` so the act is auditable in
   history), fire the auto-sign notify, and continue to `planner` in