feat(donations): contribute accounts via provider web authorization, earn New API credit

[Gaozx1]

What this adds

A public donation flow: anyone can contribute a provider account (WorkBuddy, Qoder, Trae, Devin, Command Code) and receive New API credit for it, without a console key.

Reachable at /donations, backed by:

Route	Purpose
GET /api/donations	accepted formats, and whether each supports web auth
POST /api/donations	start a web-authorization round
GET /api/donations/sessions/{id}	poll a round; settles the reward on completion
DELETE /api/donations/sessions/{id}	abandon a round
POST /api/donations/credential	pasted-credential fallback

Web authorization

Contributions use each provider's own browser login, so a contributor never hands over a raw credential. POST /api/donations creates the account, opens the provider login through the existing LoginSessionProvider path, and returns the URL to visit. Polling it drives the round to completion.

Command Code has no browser login (it authenticates with a PAT), so it keeps the pasted-credential path. GET /api/donations reports web_auth per format and the page renders credential fields only for those formats — the frontend never hardcodes which provider supports what.

Why it is public

A contributor has no console key, and the reward goes to their own numeric New API user id. The route is therefore registered outside withConsoleKey, deliberately — the credential itself is the abuse control, because the account must authorize before anything is paid out.

The invariants that matter

Four properties are pinned by tests:

1. No reward before authorization. A started round creates the account disabled and credits nothing. An unfinished round cannot carry traffic and cannot earn.
2. Exactly one credit. The reward is issued once, when the provider login reports done. A repeat poll returns the stored outcome instead of crediting again.
3. A credit failure keeps the account. If the authorization succeeds but the site rejects the credit, the response is credited:false plus credit_error, and the now-enabled account stays in the pool. Rolling back a valid contribution, or silently dropping the reward, is worse for both sides; an operator can credit manually without asking for a re-login.
4. Abandoned rounds leave nothing behind. Pending sessions expire after 15 minutes and are swept along with their placeholder accounts; cancelling does the same immediately. A settled session survives the TTL so a finished reward stays reportable, and refuses cancellation.

POST /api/donations          { "format": "workbuddy-oauth-v1", "newapi_user_id": 400 }
201 → { "session_id": "...", "auth_url": "https://copilot.tencent.com/login?...", "status": "pending" }

GET /api/donations/sessions/{id}
200 → { "status": "credited", "credited": true, "credited_quota": 500000 }

Credit call

New API validates POST /api/user/manage with the user AccessToken in Authorization plus the matching numeric id in New-Api-User. The shape is asserted in a test:

{"id": 400, "action": "add_quota", "mode": "add", "value": 500000}

1 USD = 500000 quota, which is New API's default QuotaPerUnit.

Configuration

The site is set under System settings (donation_base_url, donation_token) and read per request, so it can be changed without a restart. The token is stored as a secret and is reported only as donation_configured; it is never echoed back. A test asserts that.

Validation

go test ./...                       # 22 packages pass (Linux)
go vet ./...                        # clean
gofmt -l <changed files>            # clean
npm run build                       # clean
npm run lint                        # 0 errors
python3 scripts/release-notes.py validate   # exit 0

Verified live end-to-end against a New API 1.2.0 site:

• A web-auth round returned a real provider login URL, created the account disabled, and polling stayed pending with quota unchanged at 0 — no premature credit.
• Cancelling removed the placeholder account (404 afterwards) and made the session unpollable.
• The credit path took a contributor's quota 0 → 500000.
• A deliberately unreachable site produced the expected credited:false + credit_error with the account retained.

Note on the console UI

/donations is public, so it is intentionally not in the authenticated nav. Link to it from wherever you advertise the program.