Decide removal window for legacy handler shape migrator

[chubes4]

Problem

The codebase still ships an operator migrator for pre-1.0 scalar handler flow config fields.

Code references on origin/main (008878b6):

• inc/Core/Steps/LegacyHandlerShapeMigrator.php — migrates legacy handler, handler_slug, and handler_config fields.
• inc/Cli/Commands/Flows/FlowsCommand.php:2140-2273 — migrate-legacy-handler-shape CLI wiring.
• inc/Core/Steps/WorkflowSpecValidator.php:61-65 — strict rejection of legacy fields in workflow specs.

Related closed issue: #2103.

Why this matters

The migrator is useful as a repair tool, but it encodes an old flow config contract directly in core. For 1.0, this should have an explicit lifecycle: keep as an operator repair command, run/finalize migrations and remove, or move to a maintenance tool.

Acceptance criteria

• Decide whether LegacyHandlerShapeMigrator remains in 1.0 core.
• If retained, document it as an operator repair command and ensure normal readers/writers do not depend on legacy keys.
• If removed, confirm stored-flow migration coverage and delete the migrator/CLI wiring.
• Tests prove canonical flow config rejects legacy fields and current import/update paths do not recreate them.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.5)
• Used for: 1.0 technical-debt audit and issue drafting; Chris requested tracking issues for the findings.