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.

README.md

@@ -130,12 +130,13 @@ not settled), an `INFRA_ERROR`, any objective gate not green, or an
 exhausted budget falls back to the human sign-off pause the spec would
 have hit anyway. Re-dispatching all five lenses every round is the
 backstop that stops an editorial repair from quietly settling a design
-question. When a fork was settled in-context but the seeding issue still
-lists it open, `specify` records the resolution as a provenance-bearing
-reconciliation comment on the issue (Step 1.5), which the `scope-fork`
-juror reads via the project's issue show command — closing the blind spot where
-the in-context entry path could otherwise never clear that lens. On a
-clean sign the orchestrator commits the spec
+question. When a fork was settled in-context, `specify` gives the
+`scope-fork` juror an auditable source for it (Step 1.5): a provenance-
+bearing reconciliation comment when a seeding issue exists but lags the
+discussion, or a freshly created seeding issue when the cycle had none —
+either read via the project's issue show command, closing the blind spot
+where the in-context entry path could otherwise never clear that lens.
+On a clean sign the orchestrator commits the spec
 (`(boss-signed)` in the subject), sends a mandatory informational notify
 that names the signed capability and invites a veto, and continues to
 `planner` without stopping. A later veto is a forward correction, never