feat(ratelimit): attribute rate limit decisions to a tool and caller

[premctl]

Summary

toolhive_rate_limit_decisions_total records scope and operation_type, but nothing that says which tool or which caller a decision belongs to. With more than one entry in rateLimiting.tools, every per-tool bucket collapses into a single operation_type="tool" series, so an operator watching rejections cannot tell which configured cap is firing, and has no way to see who is hitting it.

• limitCheck now carries the tool name, and recordDecision emits it as tool_name on tool-scoped decisions. The attribute is omitted (not emitted blank) for server-scoped decisions, so existing series keep their shape.
• Caller identity goes on the span instead: Allow sets rate_limit.tool_name and rate_limit.user_id via a new recordRateLimitSpanAttribution. userID is unbounded — as a metric attribute it would multiply the decisions counter by the size of the user base — but on a span it costs nothing and answers "who is being throttled", which the counter alone cannot.

This keeps the metric answer bounded and puts the unbounded dimension where unbounded values belong.

On label cardinality (related to #6271)

#6271 is open on telemetry hardening, including tool/prompt cardinality and unbounded label value length, so it is worth being explicit that this attribute is safe on both counts.

tool_name is only ever set inside a successful bucket-map lookup — if tb, ok := l.toolBuckets[toolName]; ok and if s, ok := l.perUserTools[toolName]; ok. A tool name supplied by a caller that matches no configured bucket never reaches the attribute. The value set is therefore exactly the operator's configured tool names: bounded in count by len(rateLimiting.tools), and bounded in length by the CRD the operator wrote. TestRateLimitMetrics_UnconfiguredToolCarriesNoAttribute pins this by calling Allow with a 4096-character tool name and asserting no datapoint gains a tool_name key.

Span attributes are exported per-span rather than aggregated cumulatively, so rate_limit.user_id does not carry the residency concern that motivates #6271. Happy to truncate or drop it if you would rather keep identity out of spans entirely.

Type of change

• New feature

Test plan

• Unit tests (task test) — go test ./pkg/ratelimit/... passes. Two new tests: TestRateLimitMetrics_ToolAttribution drives a per-user tool bucket to rejection and asserts the rejection carries tool_name while server-scoped decisions carry no such key; TestRateLimitMetrics_UnconfiguredToolCarriesNoAttribute asserts caller-supplied tool names never become label values.
• Linting (task lint-fix) — golangci-lint run pkg/ratelimit/... reports 0 issues; gofmt clean.

API Compatibility

• This PR does not break the v1beta1 API, OR the api-break-allowed label is applied and the migration guidance is described above.

Does this introduce a user-facing change?

Yes — toolhive_rate_limit_decisions_total gains a tool_name attribute on tool-scoped decisions, and rate-limit spans gain rate_limit.tool_name / rate_limit.user_id. Dashboards that aggregate the counter without grouping are unaffected; those that sum over operation_type="tool" will now see one series per configured tool.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.33%. Comparing base (e30f1bf) to head (cbb708f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6517      +/-   ##
==========================================
+ Coverage   78.25%   78.33%   +0.08%     
==========================================
  Files         770      770              
  Lines       75521    75534      +13     
==========================================
+ Hits        59100    59172      +72     
+ Misses      16416    16357      -59     
  Partials        5        5              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.