Prototype CLI authorization for Devvit app maintainers

[CR29-22-2805]

Related to #272

💸 TL;DR

This PR prototypes CLI-side support for an optional maintainer role on Devvit apps.

Devvit currently limits app uploads and publishing to the app owner. That model works for individual projects, but it creates a deployment bottleneck for mature, collaboratively maintained apps: reviewed backend improvements still cannot be released unless the sole owner is available.

For Bot Bouncer, multiple contributors help review code, develop features, handle appeals, and improve moderator workflows, but every backend deployment still depends on one app owner. When that owner is occupied with the appeal backlog or other operational work, improvements that could reduce moderator workload become harder to ship.

A limited maintainer role would follow the principle of least privilege. Trusted contributors could handle routine deployment work without receiving ownership, access to sensitive owner-only capabilities, or control over project governance.

This is a prototype, not an end-to-end implementation. The checked-in API/protobuf definitions do not yet expose maintainers, and the backend must remain the authoritative enforcement boundary for every protected operation.

📜 Details

Prototype behavior

This PR adds shared CLI-side authorization logic that can classify the current developer as:

• owner
• maintainer
• unauthorized

It updates:

• devvit upload
• devvit publish
• devvit playtest

Those commands can recognize owners and designated maintainers when compatible authorization metadata is available. Existing Reddit employee override paths are preserved.

Identity matching

The prototype prefers stable Reddit account IDs over display names.

Display names are used only when stable IDs are unavailable. If both identities contain IDs, matching display names do not override differing IDs.

Authorization metadata compatibility

The shared helper can read authorization information from:

• A future backend-computed currentUserRole.
• A future typed authorization payload containing maintainers.
• The prototype app.maintainers field as a temporary compatibility fallback.

The parser accepts unknown API data rather than asserting that FullAppInfo already contains fields missing from the generated type.

Command-specific behavior

devvit upload:

• Passes the authenticated account ID and display name to the shared helper.
• Recognizes owners and maintainers.
• Preserves the employee override.
• Corrects the unauthorized override error so that it refers to uploading rather than playtesting.
• Updates the command description to mention designated maintainers.

devvit publish:

• Passes the authenticated account ID and display name to the shared helper.
• Recognizes owners and maintainers.
• Preserves the employee override.
• Uses a maintainer-aware authorization error message.

devvit playtest:

• Uses the same owner-or-maintainer authorization decision as upload and publish.
• Preserves the employee override.
• Returns a clearer error for users who are neither the owner nor a designated maintainer.

Production authorization model

The preferred production design is for the backend to return either:

• A typed current-user authorization role, or
• Action-specific capabilities such as upload, publish, playtest, and rollback.

The CLI may use those values for early feedback and clearer errors, but the server must independently enforce every protected operation.

The temporary runtime parser should be replaced with generated protobuf/API types after the backend contract is implemented.

Remaining implementation work

• Add a backend/protobuf representation for maintainers or backend-computed capabilities.
• Enforce maintainer permissions server-side.
• Add owner-managed maintainer assignment and removal.
• Add rollback authorization.
• Replace the compatibility parser with generated API types.
• Add command-level upload, publish, playtest, unauthorized-user, and employee-override tests.
• Run the relevant workspace tests and lint checks.
• Complete a successful CI run.

🧪 Testing Steps / Validation

Expanded unit coverage includes:

• Owner recognition by stable account ID.
• Maintainer recognition by stable account ID.
• Rejection when account IDs differ despite matching display names.
• Backend-computed maintainer authorization.
• Temporary compatibility with the prototype maintainer list.
• Unauthorized-user rejection.
• Missing or incomplete authorization metadata.
• Owner and maintainer app-version write eligibility.
• Maintainer-aware error messages.

Validation completed:

• git diff --check
• Guarded source transformations verified against the expected source blocks.

Full workspace tests have not yet completed successfully. A prior dependency installation attempt failed because packages/apps/devvit-dev-bot/package.json references devvit@0.13.6-dev, which was unavailable from the public npm registry.

GitHub Actions has not yet produced a workflow run for the current PR head.

✅ Checks

• CI tests (if present) are passing
• Adheres to code style for repo
• Contributor License Agreement (CLA) completed if not a Reddit employee