Bind Ops workflows to separate App identities

[abrichr]

Why

Ops still lets scheduled and manual workflows use broad repository identities. The Docs sync also writes to main. That model can't enforce the separate lifecycle, Docs, backup, and operator authorities required by the target-state protection policy.

What changed

The lifecycle projection now accepts only the configured lifecycle App identity. The Docs sync accepts only the configured Docs App identity. Both verify the actor, App, installation, source commit, and idempotency inputs.

Docs generation now pushes one automation branch and opens a pull request. Its workflow token never writes to main. The Production lifecycle check runs on every pull request.

The eight other manual workflows reject the lifecycle App before any effect job can start. Their concurrency keys include the workflow and event, and they don't cancel an active effect run.

Do not merge yet

This branch doesn't create an App, environment, protection rule, or branch. The exact App identities, repository installations, variables, private keys, and protected environments must exist before these workflows can run. PR #151 must then bind the final workflow files and exact identities before protection is applied.

Checks

• 264 tests passed, plus 3 subtests.
• Ruff passed for the new Python code.
• The lifecycle projection render check passed.
• The strict MkDocs build passed.
• YAML parsing and diff checks passed.