fix(api): bind HTTP maintenance apply to the plan's token and ref

Closes the two gaps the review of #1219 found in the HTTP continuity maintenance path.

Token. A compaction plan carries before_revision and no plan_token. The CLI promotes the revision to the token, but /api/continuity/plan and /apply did not, so HTTP compactions journalled as compact:<table>:<ref>:None. Two plans at different revisions then shared one id (the second was refused with conflicting_claim), and the CLI and HTTP gave the same plan different ids. The derivation now lives in one place, phlo.operations.maintenance_plan_token, and the CLI plan, HTTP plan, and HTTP apply all use it. The HTTP plan response echoes the derived token in both plan_token and plan.plan_token.

Ref. ContinuityApplyRequest.ref defaulted to "main", so a plan for another ref applied without repeating ref mutated main. As in the CLI, which reads the ref only from the plan file, the plan now owns its ref. ref is optional with no default, and a request ref that disagrees with the plan returns 400 {"error": "ref_mismatch", "identifiers": [<request ref>, <plan ref>]} before any provider call.

Dagster maintenance ids are unchanged.

Tests. The maintenance API test now uses a compaction-shaped fake that returns before_revision only. The second apply uses a real second /plan response, and the test asserts the journalled ids compact:silver.orders:main:101 and ...:102. It also covers a feature-ref plan applied with a mismatched ref (refused, nothing executed) and without ref (executed on feature). On the old handlers the test fails with '' == '101'.

The support manifest maintenance reason now records this behaviour; both copies are identical and the manifest validator passes.

Verification: make check passed. The phlo-api package lane passed (1368 passed, 1 skipped). tests/cli/test_operations_maintenance.py passed (16). validate_support_manifest.py and check_version_drift.py passed.