fix(weave): call_end_v2 UPDATE on primary key, fix no-op

[gtarpenning]

Jira: https://coreweave.atlassian.net/browse/WB-35267

Summary

• call_end_v2 on a calls_complete project runs a lightweight UPDATE keyed on the client started_at; a wrong/omitted value matched 0 rows, leaving the call permanently unfinished while the endpoint returned 200.
• Fast path keys an existence check + UPDATE on the full PK (project_id, started_at, id); fallback recovers the real started_at by (project_id, id) and raises NotFoundError (404) if the start is truly absent.

Performance

The extra read only runs on the eager call/end -> calls_complete path (_update_call_end_in_calls_complete). Last 7d in prod: that path fired 2,486 times vs ~135k v2 calls/complete writes -> ~1.8% of (calls/complete + call/end) hits, ~0.04% of all ~6.9M call ends. Added cost is one PK point lookup before the existing UPDATE. Local benchmark (1M-row single-project calls_complete clone, CH 26.3):

op	p50	p95
added full-PK existence SELECT	3.4ms	5.8ms
existing lightweight UPDATE	5.3ms	7.5ms
added latency (+ms)	+3.4ms	+5.8ms
added latency (+%)	+64%	+78%

Testing

clickhouse-backed regression test: mismatched started_at still finishes, unknown id raises NotFoundError.

[wandbot-3000]

Preview this PR with FeatureBee: https://beta.wandb.ai/?betaVersion=c3070831e15c568d7f57bdf0f1e3fe1ec8823c50

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[jwlee64]

Why were the started_ats mismatching in the first place, It seems like that would be a fair assumption.

But i guess with the 404 we can surface how often this happens more in our alerting

[gtarpenning]

Why were the started_ats mismatching in the first place, It seems like that would be a fair assumption.

But i guess with the 404 we can surface how often this happens more in our alerting

@jwlee64
this was discovered when claude wrote a smoke test that had a bug, was setting started_at on the call end to the call end ended_at for some reason, and nothing was working. I think this is a reasonable tradeoff, doesn't add much latency and always does the right thing.