ops(metadata): provision least-privilege repository settings writer

[seonghobae]

Operational blocker

PR #1576 adds the organization-owned desired-state reconciler for repository descriptions, GitHub Topics, and GitHub Pages settings. Audit mode needs no write credential, but live apply mode intentionally fails closed until a dedicated repository-settings identity exists.

Do not reuse reviewer/model/provider credentials or silently broaden the ordinary workflow GITHUB_TOKEN.

Required authority

Provision a dedicated GitHub App installation token path or other approved short-lived credential exposed to the protected central workflow as CWL_REPOSITORY_METADATA_TOKEN with the minimum permissions needed by the managed repositories:

• repository Administration: write for PATCH /repos/{owner}/{repo} description/homepage changes and PUT /repos/{owner}/{repo}/topics;
• repository Pages: write plus Administration write only where GitHub Pages creation/update is enabled in the desired-state manifest;
• no Issues/PR/review/merge/release/package/Actions-secret/model-provider authority unless independently justified.

Prefer a GitHub App restricted to the explicit managed repository set over a long-lived personal token. Keep the credential unavailable to pull-request code and model processes.

Acceptance

1. PR feat(metadata): reconcile repository descriptions, topics, and Pages #1576 integrates through normal protected governance with exact-head quality/security/review evidence.
2. Repository Metadata Reconciliation audit mode reports expected drift on a protected-main run.
3. Apply mode obtains the dedicated credential without exposing it in logs/artifacts and updates one canary repository's description/topics.
4. A fresh live REST read proves the exact description/topics now match config/repository-metadata.json.
5. When a repository's Pages intent is later enabled, the same path creates/updates GitHub Pages and a fresh Pages endpoint read proves the published source/settings; source/workflow definition alone is not completion evidence.
6. Revoking or removing the dedicated identity makes apply fail closed and leaves audit mode usable.

This issue owns external credential/App provisioning only; desired-state semantics and reconciler implementation remain in #1576.

[seonghobae]

Fresh live reconciliation evidence after #1582 reached protected main:

• ContextualWisdomLab/ThreadWeave already satisfies both repository-owned preconditions on its default branch: the exact-cased Ask DeepWiki badge is present and docs/index.md exists on main.
• Its live repository settings still have the old long README-derived description, topics=[], and has_pages=false, so the requested public state has not converged and Pages publication must not be claimed.
• The current protected-main Repository Metadata Reconciliation workflow supplies apply-mode GH_TOKEN from secrets.PR_REVIEW_MERGE_TOKEN, whereas this issue's least-privilege contract calls for a dedicated CWL_REPOSITORY_METADATA_TOKEN / repository-settings identity.

This makes ThreadWeave a useful canary because missing README/docs preconditions cannot explain its drift. Please treat the remaining owner-side work as: provision the dedicated short-lived/App-backed settings credential, wire protected-main apply to that credential through normal governance, then run/re-run reconciliation and re-read ThreadWeave description/topics/Pages plus the published Pages URL/content before closing. Do not broaden reviewer/model credentials or treat the merged workflow definition itself as completion evidence.

[seonghobae]

Owner-side credential isolation is now advanced in #1625. That PR removes PR_REVIEW_MERGE_TOKEN from the repository-metadata apply job, requires CWL_REPOSITORY_METADATA_TOKEN explicitly, adds a fail-closed preflight, and adds a regression contract that rejects reuse of the review/merge credential in the apply lane. It intentionally does not close this issue: protected-environment/App provisioning is still required before live mutations can succeed, followed by ThreadWeave canary description/topics/Pages verification. Current #1625 exact-head metadata validation is running; security/SAST/Scorecard checks already completed successfully while several other exact-head checks remain queued.

[seonghobae]

Fresh owner-side status after #1625 integrated to protected main@30f55d10e200673493f824886aa891cb3b099b7e: the metadata reconciliation apply job now exclusively requires CWL_REPOSITORY_METADATA_TOKEN and fails closed when it is absent. The reusable reconciler and its Pages/description/topics verification contracts are therefore source-complete on protected main; the remaining blocker is the external protected-environment/GitHub App credential provisioning described by this issue.

No live repository-settings convergence is claimed yet. Public repositories such as bandscope, saju-caldav, governance-risk-compliance, metering-billing-platform, and learning-interoperability-contracts still report has_pages=false where publication is intended, and j-planner remains a useful positive control with Pages already enabled. Continue to require an authorized least-privilege App/short-lived credential, then re-run the protected reconcile lane and verify live REST state plus published HTTPS content before closing this issue. The current connector surface does not expose secret/App provisioning, so there is no safe in-repository substitute for this final external authority step.