Config new limits for higher concurrent users

[automoto]

increasing higher concurrent user limits for high scale services.

[greptile-apps]

Greptile Summary

This PR adds configurable per-tenant realtime connection envelopes and raises the compiled limits for higher service tiers.

• Adds persisted sustained and temporary connection limits with validation, auditing, and control-panel management.
• Resolves connection limits in the authoritative API-key lookup and applies changed envelopes during WebSocket admission.
• Updates tier defaults, generated database code, templates, and unit/integration coverage.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
internal/realtime/server.go	Realtime admission now consumes the connection envelope resolved with the API key, while retaining explicit environment-limit precedence.
internal/tenant/sql.go	API-key resolution maps the authoritative joined connection-limit columns into the request-scoped tenant context.
internal/db/queries/api_keys.sql	The API-key lookup now joins the current per-tenant connection override without introducing a separate process cache.
internal/ratelimit/connection_cap.go	Higher tier defaults and a bounded custom-limit ceiling are introduced while preserving burst admission semantics.
internal/controlpanel/rate_limits.go	Adds validated, audited persistence and clearing of tenant-specific connection envelopes.
db/migrations/0044_connection_limit_overrides.up.sql	Creates the connection-limit override table with referential integrity and sustained, ceiling, ratio, and absolute-limit constraints.

Sequence Diagram

sequenceDiagram
    participant Admin as Platform Admin
    participant CP as Control Panel
    participant DB as PostgreSQL
    participant MW as Tenant Middleware
    participant WS as Realtime Admission
    participant Cap as Leased Connection Cap
    Admin->>CP: Set or clear tenant envelope
    CP->>DB: Persist sustained and ceiling
    MW->>DB: Resolve API key and current envelope
    DB-->>MW: Tenant tier and optional override
    MW->>WS: Attach resolved API-key facts
    WS->>Cap: Acquire using resolved envelope
    Cap-->>WS: Admit or reject

Loading

_{Reviews (3): Last reviewed commit: "Resolve connection override consistency" | Re-trigger Greptile}

[greptile-apps]

Stale elevated cap survives reductions

If a tenant's elevated override is cached on one process, an administrator lowers or clears it on another process, and the next refresh fails, the error path preserves the former elevated limits. tenantCapLimits then continues passing those stale limits to admission, causing WebSocket connections to be admitted above the newly persisted envelope until a refresh succeeds.