Priority queue response gets its own @id

[tomcrane]

What does this change?

GET /customers/{customerId}/queue/priority returns the priority queue's own counts, but its @id was /customers/{customerId}/queue — the main queue's identity — and all its collection links were the main queue's links. Two different resources returned bodies distinguishable only by their counts, and the priority response contained a priority link pointing back at itself under the main queue's URL space. Cause: CustomerQueueConverter.ToHydra had no queue-name awareness, so the model's UriTemplate always stamped the main-queue identity.

This PR makes the converter append the queue name to the @id for any non-default named queue, so the priority response now self-identifies as /customers/{customerId}/queue/priority.

The collection links (batches, active, recent, priority) deliberately remain the main queue's URLs: batches submitted to the priority queue genuinely appear in those shared collections (the documentation already explains this), and no per-name sub-routes (/priority/batches etc.) exist — auto-generating links off the new @id would have produced four dead links. Integration tests assert both halves: the priority @id, the shared batches link, and the unchanged default-queue identity.

Breaking Changes

Caution

This PR introduces breaking changes.

Service	Description	Notes
API	GET /customers/{customerId}/queue/priority response @id changes from .../queue to .../queue/priority	Counts and all other properties unchanged; clients comparing or dereferencing @id will see the new value