Priority tool resolver can annex an unlisted backend's tool name

[JAORMX]

Summary

Split out of the #6075 review (#6075 (comment)), where @jhrozek flagged this as pre-existing on the tools path and worth its own issue: the same name-annexation hole that #6075's review closed for prompts exists for tools under the priority strategy today.

Details

PriorityConflictResolver drops every non-winning candidate for a conflicting tool name — including candidates from backends that are not listed in priorityOrder at all and were therefore never rank-compared (pkg/vmcp/aggregator/priority_resolver.go:125-132, selectWinner at :147-167).

Cedar's tool resource identity is name-only — Tool::"<advertised name>", with no backend or workload attribute anywhere in pkg/authz/authorizers/cedar (cedar/core.go:1049). Whoever wins an advertised name inherits every authorization policy written for it.

Combined effect: an unlisted backend's uniquely-named tool can be annexed by a listed backend that later ships a tool of the same name:

1. Backend b2 (not in priorityOrder) advertises tool deploy; no conflict exists, the name passes through bare. An operator writes permit(... resource == Tool::"deploy") for it.
2. Backend b1 (listed in priorityOrder) later adds a tool named deploy.
3. b1 wins the conflict by rank; b2's tool is dropped. The existing permit now authorizes b1's different tool, with no config edit and no signal to the operator. b2's tool becomes unreachable.

The forbid direction fails closed (the loser is dropped, not re-advertised under another name), but permit policies are silently redirected to the annexing backend.

Possible directions (from the review discussion, not prescriptive)

• Treat a collision involving a backend absent from priorityOrder differently from a rank-compared collision (e.g. prefix or drop rather than silently awarding the name to the listed backend).
• Longer-term: give Cedar entities a backend/workload attribute so policies can bind to more than the bare name.

Related: the prompts-side counterpart of this was addressed in #6075 (loser dropped, invariant documented) with a follow-up PR tightening the ambiguity handling.