[follow-up] /reconcile --task <id> filter (deferred from FORGE-100)

[firatcand]

Follow-up to #135 (P2.5-T09).

The #135 plan listed --task <id> as an in-scope flag for scoping --pull / --push to a single task on both sides, with INVALID_ARGS on unknown ID and a dedicated integration test. The flag was deferred during implementation (per [user-prefers-minimum-over-expansion]] — none of the locked acceptance criteria depend on it, and the bidirectional flow without scoping is enough for the team-mode minimum architecture).

Scope

• Add --task <id> to parseReconcileArgv in src/cli/orchestrate-reconcile.ts
• When set: filter diffPull / diffPush results to only the task whose id matches
• Error INVALID_ARGS with message unknown task id: <id> when the id isn't found in phases.yaml AND no matching tracker_issue_id is in the tracker results
• Skill UX: surface the filter in dry-run preview ("scoped to P2.5-T09 only")
• Tests in test/unit/cli/orchestrate-reconcile.test.ts and test/integration/cli/reconcile.e2e.test.ts

Acceptance

• forge orchestrate reconcile --pull --task P2.5-T09 --dry-run --json returns a PullPlan whose entries all carry task_id: P2.5-T09 (or are scoped via tracker_issue_id)
• Unknown id exits 1 with INVALID_ARGS
• Integration test covers both directions with the filter

Source

plans/tasks/FORGE-100.plan.md §1, §4 edge case 9, §3 verb input shape.
QA report on the #135 ship train flagged this as the only blocker; deferred to a follow-up to keep #135 scope frozen at the locked ACs.

Out of scope

Nothing additional — purely the --task flag wiring. Underlying diffPull / diffPush already work on arbitrary inputs; this is a thin filter layer on top.