feat: aggkit-proxy: add CORS support for REST and WebSocket endpoints

[joanestebanr]

🔄 Changes Summary

• New REST.CORS config on the shared RESTConfig/HTTPServer (common/config.go, common/httpserver.go): Enabled, AllowedOrigins, AllowedMethods, AllowedHeaders, AllowCredentials, MaxAge. Wraps the gin engine with rs/cors when enabled. Disabled by default — no behavior change for existing deployments.
• [REST.CORS] section added to the proxy's default config (proxy/config/default.go), disabled, with AllowedMethods/AllowedHeaders covering the common REST verbs and any header, ready to flip on.
• The bridgetracker's WebSocket endpoint now enforces the same origin policy: browsers never CORS-preflight the Upgrade request, so Access-Control-* headers can't restrict it — instead the handshake itself is rejected (403) for a disallowed origin, via a new CORSConfig.OriginAllowed check wired from REST.CORS down into bridgetracker.Config → wsHandler's websocket.Upgrader.CheckOrigin. With CORS disabled (default), the WS endpoint stays fully public, same as before.
• Fixed two bugs uncovered while adding tests, both in how corsHandler maps AllowedOrigins onto rs/cors:
  • rs/cors always answers Access-Control-Allow-Origin: * when AllowedOrigins contains "*", even with AllowCredentials set — browsers reject that combination outright. Now routed through AllowOriginFunc so the origin is actually reflected, matching the documented intent.
  • rs/cors treats an empty AllowedOrigins as its own default of "allow every origin" — the opposite of what CORSConfig.AllowedOrigins documents and of OriginAllowed's fail-closed behavior for the WebSocket handshake. Enabling CORS without filling in AllowedOrigins used to silently open the REST server to every origin while denying the WS endpoint under the same config. Now forced to deny-all via AllowOriginFunc, consistent with the docs and with WS.
• docs/common_config.md and docs/bridgetracker/API.md updated accordingly.

⚠️ Breaking Changes

• 🛠️ Config: New optional [REST.CORS] section on every RESTConfig-backed service (proxy, aggsender-rpc, bridgeservice, autoclaim-api, …), not just the proxy. Fully backward-compatible: Enabled defaults to false.

📋 Config Updates

[REST.CORS]
Enabled = false
# Empty denies every origin once Enabled is true; use ["*"] to allow any origin.
AllowedOrigins = []
AllowedMethods = ["GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS", "HEAD"]
AllowedHeaders = ["*"]
AllowCredentials = false
MaxAge = "12h"

✅ Testing

• 🤖 Automatic: common/httpserver_test.go (CORS disabled/enabled, preflight, AllowCredentials+wildcard reflection, empty-AllowedOrigins deny-all, corsHandler mapping), common/config_test.go (CORSConfig.OriginAllowed table), bridgetracker/websocket_test.go (TestWSCORSOriginCheck: handshake allowed/rejected per origin policy). make test-unit, make lint both pass.

🐞 Issues

• Closes feat: aggkit-proxy: Add CORS headers #1806

📝 Notes

• CORS is added at the shared RESTConfig/HTTPServer level rather than proxy-specific, so any service built on it gets the capability for free.
• WebSocket origin enforcement is a genuine server-side access check (unlike CORS headers, which are a browser-side courtesy) — see the new "Cross-origin access" section in docs/bridgetracker/API.md.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 13c8c89f2d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".