feat(rate): persist capability optimizer requests in workspaces

[d-sorgcodexagent]

Summary

• persist the existing capability-optimization request contract in explorer-session v5 workspaces
• retain the full validated request as application authority while overlaying only fields represented by PyQt6 and React controls
• reject unsupported interactive bases, alternate units, covariance matrices, and reordered parameters before UI or File/Open mutation
• invalidate stale optimizer results after workspace replacement and gate native worker publication by identity and generation

Stack

• Base: feat/4144-workspace-variation-study / draft PR feat(rate): persist variation study workspaces #4343
• Implementation head reviewed independently: 5730e74752ffb84ab3560bed6318b7d97b6e627d
• This is a bounded child slice for [Ball Flight] Optimize shot design for player capability, distance, and dispersion #4197 and Workspace view compositor: Impact, Swing, Flight, and synchronized multi-view #4225; it does not complete either issue.

Verification

• 71 focused Python workflow, workspace, File/Open, PyQt6, and manifest tests
• 70 focused React contract, workspace, File/Open, and UI tests
• Ruff check/format and pinned MyPy 1.13
• TypeScript type-check, zero-warning ESLint, and Vite production build (211 modules)
• campaign-manifest, docs-governance, module-size, changed-file, and diff gates
• independent exact-head review: PUBLISH

Deliberate limitations

• workspace persistence covers reproducible request inputs, not results, observations, progress, workers, or cancellation handles
• optimizer execution parity, wind-aware optimization inputs, UpstreamDrift parity, protected CI/review, integration, and release remain open
• legacy v1-v4 workspaces require an explicit current capability fallback; the application does not fabricate one

Closes no issue.

[github-actions]

⚠️ SPEC.md Update Required

Source files were modified in this PR but SPEC.md was not updated.

Per the Specification-Driven Development Policy:

• Any PR that adds, removes, or changes functionality must update SPEC.md
• Update the relevant sections (features, architecture, tests, dependencies, etc.)
• Bump the Spec Version if making substantive changes

To resolve:

1. Update SPEC.md to reflect your changes, OR
2. Add the spec-exempt label if this PR genuinely doesn't affect the spec (e.g., pure refactor with no behavior change)

This check is enforced by the spec-check CI workflow.