[Bug] Builder reads wrong spec when the protocol is tick (when --amends is omitted)

[timeleft--]

Bug Report: af spawn --protocol tick uses issue number for spec resolution when --amends is omitted

Problem

When spawning a TICK builder, the positional argument is the issue number, but af spawn uses it to resolve the spec file path.
For TICK protocol, the issue number and the amended spec number are typically different — TICK amends an existing spec,
triggered by a new issue.

  Example:
  af spawn --protocol tick 5          # Issue #5 (JSON parsing bug)
  # Expected: spec 3 (trust-gate) — the spec being amended
  # Actual:   spec 5 (pull-daemon) — matched by issue number

  Spawn output showed:
  Spec: /home/younes/git/MachineWisdomAI/fava-trails/codev/specs/5-pull-daemon.md

The builder received 5-pull-daemon.md in its prompt context instead of 3-trust-gate.md. It still completed successfully
because the GitHub issue description and the amended spec/plan (committed to main) contained enough context — but the
{{spec.path}} in the TICK builder prompt template pointed to the wrong file.

Root Cause

In spawn.ts:254-260:

  const specLookupId = (protocol === 'tick' && options.amends)
    ? String(options.amends)
    : projectId;

When --amends is omitted, specLookupId falls back to projectId (the issue number). The --amends flag is optional, with no
validation requiring it for TICK protocol.

Impact

• Builder prompt's {{spec.path}} points to the wrong spec file
• Builder may read and attempt to amend the wrong spec
• Silent failure — no error or warning when --amends is missing for TICK
• In this case the builder succeeded anyway due to sufficient context in the GitHub issue and committed amendments, but this
  is luck, not correctness

Suggested Fix

Option A (minimal): Require --amends for TICK protocol:

  if (protocol === 'tick' && !options.amends) {
    fatal('--protocol tick requires --amends <spec-number> to identify the spec being amended');
  }

Option B (also persist): Additionally store amends in porch state and pass it into TemplateContext so the builder prompt can
explicitly reference both the issue and the amended spec:

  // In TemplateContext interface:
  amends?: { spec_number: string; spec_path: string };

  // In TICK builder prompt template:
  ## Amendment Context
  This TICK amends spec {{amends.spec_number}} at `{{amends.spec_path}}`.
  The triggering issue is #{{issue.number}}: {{issue.title}}.

Environment

• codev v2.1.0
• af spawn --protocol tick 5 (without --amends 3)
• Spec 3 (3-trust-gate.md) was the intended amendment target
• Spec 5 (5-pull-daemon.md) was incorrectly resolved

Reproduction

  # Setup: project with specs 3 and 5, GitHub issue #5 that amends spec 3
  af spawn --protocol tick 5
  # Observe: Spec: codev/specs/5-pull-daemon.md (wrong)

  af spawn --protocol tick 5 --amends 3
  # Observe: Spec: codev/specs/3-trust-gate.md (correct)

[waleedkadous]

On it! Working on a fix now.

[waleedkadous]

Fixed in PR #570 — af spawn --protocol tick now requires --amends <spec-number> and fails fast with a clear error message if omitted. Will ship in v2.1.2.