### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

`LiteLLM_DailyTagSpend` can accumulate many physical rows for the same logical spend key when `custom_llm_provider` is `NULL`. The repeated inserts increase table/index size and can make daily-spend flushes consume most of the PostgreSQL CPU. Spend reporting also becomes fragmented across duplicate rows.

I expected repeated daily tag-spend updates for the same `(tag, date, api_key, model, custom_llm_provider, mcp_namespaced_tool_name, endpoint)` key to update one row.

The current implementation does not enforce that behavior when a conflict column is nullable:

1. The Prisma schema makes `tag`, `model`, `custom_llm_provider`, `mcp_namespaced_tool_name`, and `endpoint` nullable, then includes all of them in a normal composite unique constraint: [`schema.prisma#L878-L900`](https://github.com/BerriAI/litellm/blob/3f9b71c1a45e870d1789ee105bd59b9274bb0d74/litellm/proxy/schema.prisma#L878-L900). 2. PostgreSQL treats `NULL` values as distinct in a normal unique constraint, so the constraint permits multiple otherwise-identical rows when any conflict…