Investigate + design config-as-code for the GITTENSORY_REVIEW_DRAFT public draft-submission flow

[JSONbored]

Part of #4092.

Problem — this is a design question, not a known gap

GITTENSORY_REVIEW_DRAFT (src/services/draft.ts, src/api/routes.ts) gates a PUBLIC OAuth draft-submission API surface, ported from reviewbot — a fundamentally different shape from the other flags in this epic (it controls whether an API ENDPOINT exists/responds at all, not a per-PR review behavior). Whether "per-repo config-as-code" is even the right model here needs its own decision.

Requirements

• Characterize exactly what GITTENSORY_REVIEW_DRAFT currently controls (read src/services/draft.ts + the api/routes.ts call sites in full) — is it a single global on/off for the whole instance's public API surface, or does it already have any per-repo dimension?
• Decide whether this belongs in the "config-as-code, per-repo" bucket (e.g. "which repos accept public draft submissions" could plausibly be a real per-repo config) or the "bare necessity, env-var-only" bucket (e.g. if enabling this exposes an unauthenticated public endpoint, an operator may legitimately want that gated by something more deliberate than a per-repo YAML file on the same box)
• Write up the reasoning either way

Deliverables

• Written investigation + decision
• If per-repo config makes sense: implement using the shared resolver + tests
• If not: explicit sign-off with reasoning recorded

Expected outcome

A definitive, reasoned answer for whether/how config-as-code applies to the public draft-submission flow.

Effort

S (investigation) to M (implementation, only if warranted).

[linear-code]

JSO-3157

[JSONbored]

Closing as investigated, no code change warranted — env-var-only is the correct model here, not per-repo config-as-code.

What GITTENSORY_REVIEW_DRAFT actually controls (read src/services/draft.ts in full + every api/routes.ts call site):

• It is a single deploy-wide on/off for whether the /v1/drafts endpoint family (POST /v1/drafts, GET /v1/drafts/:id, GET /v1/drafts/auth/callback, requiresApiToken's unauthenticated exemption for those paths, and the submit-draft queue handler) exists at all on this Worker instance. When off, every handler 404s and the queue handler no-ops (draftFlowEnabled(env) short-circuits all four entry points) — byte-identical deploy, same pattern as the other converged flags.
• It has no per-repo dimension to gate, unlike rag/reputation/unifiedComment/safety. Those features activate per repo gittensory is installed on and reviewing PRs for — resolveConvergedFeature(env, manifest, feature, repoFullName) loads repoFullName's own .gittensory.yml and reads features: from it. The draft flow has no "repo under review" in its request path at all: it's an anonymous public visitor submitting content, OAuth-authenticating with their own GitHub account, then forking and PR'ing against one hardcoded destination repo (DEFAULT_PUBLIC_REPO = "JSONbored/awesome-claude", overridable only by the single env var DRAFT_PUBLIC_REPO, never a per-repo map). There is no "which repos accept public draft submissions" question to answer — there is exactly one target per deployment, and it isn't the repo whose config would be doing the gating.

Why config-as-code (.gittensory.yml features:) is the wrong bucket, not just an unbuilt one:

1. No coherent "whose config" answer. The features: override lives in the reviewed repo's own .gittensory.yml (repo-writable, lower-trust than the operator — see the safety force-on-only asymmetry in feature-activation.ts, fix(review): features.safety is per-repo disableable via .gittensory.yml even when the operator enabled it globally #2269). For the draft flow there is no reviewed repo in the request path to read a manifest from. The only candidate would be the destination repo's own config controlling whether its own public unauthenticated intake endpoint is live — i.e. letting a repo-writable file (mergeable via a normal PR to that repo) toggle on a surface that encrypts and stores other users' GitHub OAuth tokens and opens forks/PRs using them. That's a strictly worse trust boundary than an operator-only env var, not a config-as-code win.
2. It's a security-sensitive global surface, not a review behavior. Enabling it means: an unauthenticated public endpoint accepts JSON, starts a GitHub OAuth flow, encrypts+stores a real user access token, and later uses that token server-side to fork a repo and open a PR autonomously. That is exactly the "bare necessity, deliberate redeploy" shape the issue's second bucket describes — an operator should have to consciously flip this with a redeploy (plus set the OAuth client id/secret and DRAFT_TOKEN_ENCRYPTION_SECRET Worker secrets, which are already env/secret-only and can't live in a repo-writable YAML anyway), not have it toggle-able per-repo through content that ships in the reviewed repos themselves.
3. Consistent with the two already-correct reference examples the epic cites (testGeneration, contentLane): both are genuine per-reviewed-repo review behaviors. Draft submission isn't a review behavior at all — it doesn't run during any PR review, has no repoFullName to key an override on, and its one fixed destination repo is deployment config, not review config.

Decision: GITTENSORY_REVIEW_DRAFT (and its companions DRAFT_PUBLIC_REPO/DRAFT_BASE_REF/DRAFT_TOKEN_ENCRYPTION_SECRET) stay env-var-only. No migration onto feature-activation.ts's resolver — there is no per-repo dimension for it to resolve. No code change made.

See #4092 for the epic.