The forge is an OpenID Connect provider: discovery, id_token, userinfo and rotating JWKS, landed from pull #1404 #1459

Part of #666, the owner's ask. Pull #1404 built this part and went red only on the gate list. #749 (hosted apps sign in through OIDC) and #748 (sign in with your forge) are the parts that use it, and they wait for this.

Done looks like

• [ ] Start from today's main and bring over #1404's change.
• [ ] GET /.well-known/openid-configuration lists the issuer, the endpoints, the scopes (openid, ro, rw, admin and the OIDC standard ones) and the signing algorithm.
• [ ] scope=openid with a nonce goes through the existing authorize and PKCE flow, and /oauth/token returns an id_token next to the access token. /oauth/userinfo answers for that token.
• [ ] /oauth/jwks publishes the current key and the previous one. Rotation is tested: a token signed with the previous key still verifies until it expires.
• [ ] There is no second credential system: the id_token comes from the same grant as the ro/rw token.
• [ ] Every new test/*.test.ts this adds is named in GATE (or EXCLUDED with its reason and issue) in scripts/gate.ts in the same commit, and bun test test/check-list.test.ts passes before the push.
• [ ] Before pushing, run bun x tsc --noEmit and the test files this touches (the sandbox sets FORGE_TEST_SOCKET, so the server suites run there), and quote both results in the pull.

Files: the OAuth module under src/actions or src/core, src/http/api.ts, test/oauth-flow.test.ts, test/oauth-discovery.test.ts. Risk: the signing keys must live in the database or under FORGE_APP_DATA, never in the repository. Builder: sentinel.