Add per-issue planning artifact requirements

[rochecompaan]

Part of #191.

Follow-up to #180. Implement this after the planning-pr-v1 workflow lands.

Blocked by: #180

Goal

Allow each Issue Run to declare its own specification and plan requirements through issue labels instead of relying only on repository-wide approval switches.

Scope

• Define a provider-neutral planning requirement contract for specifications and plans.
• Support three effective states for each artifact: not required, required without review, and required with review.
• Define and document the issue labels that select those states.
• Treat a review requirement as implying that the artifact is required.
• Read the requirement labels after acquiring the Issue Run lock and before any planning side effect.
• Derive the required planning phases from the effective issue contract using the pull request machinery delivered by Consider publishing specs and plans as pull requests instead of issue uploads #180.
• Persist the effective contract in durable run state so resume behavior is deterministic.
• Define deterministic behavior when requirement labels change after a run starts.
• Preserve a documented migration path for repositories and existing runs that use the Consider publishing specs and plans as pull requests instead of issue uploads #180 configuration switches.
• Add behavior tests for the supported requirement combinations and resume paths.

Out of scope

• Resolving artifacts from parent issues.
• Coordination-only Issue Runs that stop without implementation.
• Arbitrary workflow definitions or user-defined phase ordering.
• Changes to the pull request provider adapters delivered by Consider publishing specs and plans as pull requests instead of issue uploads #180 unless required to carry the effective contract.

Acceptance criteria

• Two issues in the same repository can select different planning requirements using labels.
• An issue can require neither artifact, either artifact, or both artifacts.
• Specification and plan review can be required independently.
• Review requirements cannot produce a contradictory contract in which their artifact is absent.
• The phase planner creates only the phases required by the effective contract.
• A resumed run uses its saved contract and does not silently change behavior because labels changed.
• Migration behavior for Consider publishing specs and plans as pull requests instead of issue uploads #180 configuration and existing run state is documented and covered by tests.