Add entry activation authority to Control Programs

[bigboateng]

Summary

• add optional, canonical entry activation authority requirements to Control Programs
• unify entry activation and delegation consent into one exact run-scoped authorization event while keeping their scopes separate
• require human activation for Product Delivery run and update all generated host instructions
• persist schema-5 authorization records bound to program, bundle, entry, target, run, inputs, identity, and delegated scope

Safety boundaries

• activation consent never emits a reusable human authority receipt
• only the delegation scope injects run-scoped authority receipts
• provider, bootstrap, later-human-transition, and unrelated-run authority remain excluded
• unsupported entry activation authorities fail closed

Verification

• npm run test:flow-sdk
• npm run docs:check
• python3 .github/scripts/run_go_tests.py (555 tests, 10 isolated shards)
• go test -race ./...
• go vet ./...
• go build ./...
• python3 -m unittest discover -s .github/tests -p "test_*.py" -v (55 tests, 1 expected failure)
• release-note policy and git diff --check
• exact-head Locus analysis: faithful, controllable/nonblocking, event-completeness discharged

Consumer evidence

A real Cursor run resolved the configured developer identity through the exact gh api user --jq .login descriptor, obtained one combined activation/delegation approval for a single run, then resumed that same run through planning, implementation, build, test, and review without another authorization prompt. A later local-only product decision correctly blocked publication without changing the accepted authorization scope.

Do not merge until the requested two review/fix/verification cycles and required exact-head CI complete.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[github-actions]

Codex automated review

Verdict: patch is incorrect
Confidence: 0.97

The new activation boundary introduces a concrete completed-record zero-progress path, lacks migration for existing durable delegation records, and permits software-flow artifacts that its runtime cannot execute. Model-level verification is recommended before merge, particularly to enumerate every post-completion observation that can become nonterminal and every supported prior authorization schema's recovery path.

[github-actions]

Codex automated review

Verdict: patch is incorrect
Confidence: 0.97

The entry-activation flow is internally consistent for newly created records, but the durable authorization schema change strands runs created by the base revision. Model-level verification is recommended before merge: verify that every prior, expired, revoked, or completed authorization state retains a zero-authority recovery path.