release: harden provenance evidence

[steadytao]

Summary

Hardens the release provenance path and updates the post-v0.12 roadmap so the next gates focus on fixture-backed compatibility before broader expansion.

Problem

The roadmap after v0.12 still grouped some risky work too broadly and included a Docker Compose example before Docker Compose support. The release workflow also introduced a SLSA reusable workflow by version tag, which left Scorecard reporting that only 29 out of 30 third-party GitHub Actions dependencies were pinned.

Scope

What is included in this change

• Reworks v0.13 through v1.0 in the roadmap around fixture-backed compatibility, Terraform/OpenTofu state import, provider schema evidence, graph lowering, pack v1, examples, CI review and hardening.
• Removes Docker Compose from the pre-v1.0 example list while keeping Docker Compose implementation at the post-v1.0 v1.2 gate.
• Includes the already-merged release-attached SLSA provenance work in the v0.13 fixture and release-evidence gate.
• Removes the unpinned SLSA reusable workflow from the release workflow.
• Uses the pinned actions/attest action to generate the provenance bundle and attach it as planwright.intoto.jsonl.
• Removes the action-pin checker exception that was only needed for the SLSA reusable workflow.
• Updates release docs and checklist verification commands to use gh attestation verify --bundle.
• Updates the changelog under Unreleased.

Documentation

• Documentation updated:
  • docs/roadmap.md
  • docs/releases/README.md
  • docs/releases/checklist.md
  • docs/releases/signing.md
  • CHANGELOG.md

Security impact

Does this change affect security behaviour, trust assumptions, credential handling, architecture graph semantics, importer behaviour, generated infrastructure, release integrity or administrative authority

• No
• Yes

If yes, explain:

Recorded decision

Does this change require or relate to a recorded decision under docs/architecture/decisions/

• No
• Yes

If yes, list the relevant decision record or explain why a new one is needed:

Related to ADR 0007 for the release artefact boundary and ADR 0008 for fixture-backed compatibility claims. No new ADR is needed because this change refines the roadmap and release evidence path within those existing decisions.

AI assistance disclosure

Was AI used to materially assist this contribution

• No
• Yes

If yes, describe the extent of AI assistance and what was personally reviewed and verified by the submitting human contributor:

DCO

• I confirm that all commits in this pull request are signed off under the DCO