feat: add ai_user_daily_spend table and queries - #26562

P2 [CRF-2] The upsert's ON CONFLICT path does spend_micros = ai_user_daily_spend.spend_micros + EXCLUDED.spend_micros. CostMicros is int64 (signed). The table CHECK only fires when the result goes negative.

On INSERT (new row): negative cost_micros is rejected because the result itself is negative. Safe.

On UPDATE (existing row): if current spend_micros is 1000 and cost_micros is -500, the result is 500, which passes the CHECK. Spend is silently reduced.

The query comment says "Adds cost_micros to the spend" and the table drives budget enforcement (AIGOV-428). A caller bug passing a negative delta silently corrupts enforcement data: spend goes down, headroom goes up, budget appears unspent. No test covers negative cost_micros; all test values are non-negative.

Fix: validate CostMicros >= 0 in the Go dbauthz wrapper (or a shared helper) before calling the query. This produces a clear application error rather than relying on the schema-level floor. (Hisoka P2, Knov P2, Mafuuu P3, Bisky P3)

🤖

I think this is relevant, but dbauthz is the database-related authorization layer. This should be done at the application layer instead. The schema CHECK remains the data-integrity backstop.

Nit [CRF-1] The query filters on user_id, effective_group_id, and day >= period_start, but the name conveys only User and Since. A caller reading the name could expect spend across all groups. A name like GetUserSpendByEffectiveGroupSince would be more precise, matching the pattern of other queries in this file (GetGroupAIBudget, GetUserAIBudgetOverride). (Netero)

🤖

Both UserID and EffectiveGroupID are required in Params, so the filter scope is clear at every call site. I think the current name is enough, but happy to change it if there is agreement

This operation is performed by the AI Bridge daemon, so we're checking that it has Update on AIBridgeInterception. The operation isn't actually modifying an interception, though. But seems the best approach with what we currently have.

Other alternatives:

• Introduce a new resource for cost control. Would this make sense?
• Follow the token usage pattern, where we validate that the actor matches the interception's initiator via authorizeAIBridgeInterceptionAction. This would require passing an interception_id here and at the database layer.

Thoughts?

Since it's performed by the daemon, we'd expect the context to have subjectAibridged, so yeah I think a new resource is the most idiomatic approach here since it is indeed a new resource in the system.

@dannykopping We can do that, but my only concern is that for group budget and user overrides budget we use operations on Groups/Users resources, not on a specific AI Cost Control resource. Would this mean that for the upcoming changes on the list groups and list members (including the spend) pages, we should include read operations on this new resource? 🤔

I don't have any strong feelings here; it's a bit murky. Having a separate resource feels like the cleanest approach, but it'd require some refactoring of the existing budget code.

Yeah, it is not entirely clear for me as well. We have two components for cost control:

• Budget config (group budgets, user overrides): these are properties of User/Group resources, so authorizing on those entities makes sense, we're updating the entity itself.
• Spend records: The write is clean, aibridged updates the user's spend, so a new resource fits. For the read we will have 2 actors:
  1. on the pre-request path aibridged reads the user's spend (resource-level makes sense)
  2. admin views the groups/members pages: this is the tricky one. These pages will include the user's spend, so this would mean that in order for admins to see this page, they need to have read operation on both Users/Groups and this new resource. Which means we would be coupling users/groups with spend. "Can read User X" would implicitly mean "can read X's spend".

As a result, for simplicity, I'll introduce a new ResourceAICostControl with just the Update action for now. Reads stay on the parent entities (User/Group). We might need to revisit this later. Let me know if this makes sense. @evgeniy-scherbina would also be good to have your opinion, since you have more context on the rbac side of things for cost control 🙂

I don't mind to keep it as it is.

• For Budget Config (Groups and UserOverrides) we treated it as extension of Groups and Users so we reused corresponding RBAC resources.
• We can treat Spend records as extension of interception (because it's an aggregation of token_usages). I understand it's not perfect, but neither is adding new resource for this specific case.

After internal discussion, we decided to keep the authorization check as is (Update on AIBridgeInterception) rather than creating a new resource. This check is enough for now, and it guarantees that only subjectAibridged and Owner roles can effectively increment user spend. We can revisit this later if needed.