feat(mcp): implement P4 governed export and promotion of runtime workflow proposals

[enricopiovesan]

Summary

Implements #1094 per spec 112-governed-workflow-promotion FR-001 through
FR-004: the non-mutating export and human-reviewed promotion path from a
completed P1 runtime workflow proposal to a reusable, versioned workflow.
No new registration mechanism is introduced — promotion still goes through
the existing, unchanged traverse_registry::WorkflowRegistry::register /
traverse-cli workflow register path.

• traverse-mcp::tools::workflow_promotion: export_workflow_candidate
  builds a plain, serializable WorkflowCandidateArtifact from a proposal
  whose trace reached Succeeded (FR-001) — never touches a registry or
  app manifest. It carries proposal/snapshot digest provenance, each
  node's resolved RiskMetadata for reviewer visibility (FR-002a), and
  best-effort reduces mappings whose source/target JSON-Pointer paths
  share a leaf segment into WorkflowNode's from_workflow_input/
  to_workflow_state shared-state model — anything else (a rename, or a
  nested path with a different leaf name) is listed in
  unconfirmed_mappings for the reviewer to resolve rather than guessed
  at. It never reads initial_input or approval-token material, recording
  both in a fixed excluded_fields audit list.
• finalize_candidate_into_definition assembles a registrable
  WorkflowDefinition from the candidate plus a PromotedWorkflowIdentity
  a human reviewer supplies (id, name, version, owner, lifecycle,
  summary, tags) — never inferred from the source proposal (FR-003).
  Performs no registration itself.
• Two real gaps in the existing WorkflowDefinition v0.1 format are
  surfaced honestly rather than worked around: it supports only a single
  direct outgoing edge per node (a branching proposal's candidate
  correctly fails registration — proven by
  a_branching_proposals_candidate_is_honestly_unregistrable), and its
  input/output model has no rename step (proven by
  export_flags_a_renamed_mapping_as_unconfirmed).
• Yank/rollback/deprecation (FR-004) needed no new code: a promoted
  workflow's Lifecycle is the same, only lifecycle mechanism
  WorkflowRegistry already has for hand-authored workflows.
• workflow_promotion_tests.rs's
  export_then_promote_then_discover_end_to_end proves the full spec 112
  Definition-of-Done chain against the real
  traverse_registry::WorkflowRegistry (not a mock): export → finalize
  with a reviewer identity → register → confirm discovery via
  find_exact and discover.
• docs/governed-workflow-promotion.md documents the design, both
  surfaced format gaps, and why no active secret-scanning is needed (the
  candidate is built exclusively from fields already proven secret-free by
  construction — ProposalTrace and everything but initial_input).

Closes #1094

Governing Spec

• 112-governed-workflow-promotion
• 070-runtime-event-sink-boundary

Project Item

Project 1 item for #1094: PVTI_lADOEbiBt84Bbyp1zg3fR9I (In Progress).

Validation

• cargo test --workspace — all suites pass, including 5 new tests for
  export/finalize/promotion covering success, rejection of a
  non-succeeded trace, mapping-rename detection, risk preservation, and
  the branching-format-gap rejection.
• cargo clippy --workspace --all-targets — clean.
• cargo fmt --check — clean.
• bash scripts/ci/coverage_gate.sh — passes: traverse-mcp at 99.13%
  (> 98% threshold); traverse-contracts/traverse-runtime unaffected
  and still at 100.00% (this PR touches neither crate).
• bash scripts/ci/spec_alignment_check.sh — clean against this PR body.

Non-goals

Matches spec 112's own "Out of scope": direct runtime publication,
automatic promotion, or bypassing human review. Nothing in this PR calls
WorkflowRegistry::register itself, opens a PR against the registry, or
grants a proposal any ongoing execution authority.