Planning-validator template-version field awareness — D-25 next action 2

feature_id: FEAT-studio-planning-validation
decision_memo: docs/pdt/2026.09.09-d25-admission-fields.md
blocked_by: OPER-146
filing_template_version: 1

## Context

PDT memo D-25 (`docs/pdt/2026.09.09-d25-admission-fields.md`) recommended a versioned `filing_template_version: N` frontmatter contract between the agent-side `fileTicketForFollowup` helper (next action 1) and the planning-validator. Kira flagged in the D-25 DISSENT section that without a version handshake, a future admission-fields addition (e.g. adding an `estimatedRiskBand` required field) would silently under-populate every old-version-templated ticket already in flight.

This ticket adds the reader half of that contract. The validator parses `filing_template_version: N` out of the body frontmatter, looks up the required-fields set for that version, and rejects tickets whose declared version does not cover the CURRENT required-fields set.

The registry lives next to the validator; adding a new required field bumps the current version + registers the delta. Old tickets keep validating against their declared version until they're re-filed or PATCHed. New tickets from the helper always declare the current version.

## Acceptance Criteria

- `apps/web/src/lib/planning-validator.ts` exports `TEMPLATE_VERSION_REQUIRED_FIELDS: Record<number, ReadonlyArray<PlanningRejectionReason>>` — the version → required-fields registry.
- `validateAdmissionFields(task)` parses `filing_template_version: N` from the body; missing/unparseable defaults to `1` (backward compat for pre-helper tickets).
- New rejection reason `template_version_stale` added to the `PLANNING_REJECTION_REASONS` tuple with a matching entry in `ADMISSION_ISSUE_MESSAGES`.
- Unit tests cover: current-version ticket passes; version=1 ticket with only version=1 fields passes; a hypothetical version=2 with required `estimatedRiskBand` rejects a version=1 ticket that lacks it.
- No behavior change for tickets already in flight — this ticket only introduces the version-awareness scaffolding; adding a new required field is a separate ticket.

## Non-goals

- Adding new required admission fields (separate follow-on tickets).
- Changing the validator's behavior for tickets without a filing_template_version line (they continue to be treated as version=1 for compat).

## Related

- Depends on the ticket-filing-helper ticket (D-25 next action 1) — this ticket assumes the helper is writing `filing_template_version: N` into new tickets.
- Unblocks any future admission-fields addition.