feat(context): scenario taxonomy and request/response contract for adr_planning_context

[kschlt]

Why

The adr_planning_context MCP tool currently accepts a free-text context_type field, which gives callers no structured way to express what kind of planning scenario they are in. This PR establishes the typed API layer — scenario enum, request model, and response packet — that the retrieval and rendering logic will build on in subsequent items.

Approach

Four named scenarios replace free-text context_type: new_adr, amend_existing, replace_supersede, and explore_options. Each maps to a projection of what context is relevant. The new ContextScenario, ChangeMode, and DetailLevel enums, combined with ContextRequest and ScenarioContextPacket Pydantic v2 models, form the contract hub. PlanningContextRequest gains five backward-compatible optional fields so no existing callers break — they continue working without changes. All ten new types are exported from the context package. The design favours progressive disclosure: callers can provide as little as a scenario name and get a useful response, or add scope hints and target refs for more precise projection.

What Was Tested

• 41 new unit tests across two files: scenario enum resolution and projection logic coverage, and PlanningContextRequest backward-compatibility (all new fields optional with defaults, existing callers unaffected).
• Full quality suite (ruff, mypy, black, 592 unit/integration tests) passes cleanly.

Risks

Downstream callers using a free-text context_type string will eventually need to migrate to one of the four named scenarios once retrieval logic starts consuming the enum. No breakage today — the field remains backward-compatible — but migration will be required before the enum-driven retrieval is enabled.