v0.10.0 — the pinned queue becomes a wall

v0.9.0 put the queue into the credential and made it the default for list_cases. That was half a boundary and therefore none: every other action addresses a case by id or by the number a customer quotes, and a number is something an agent can simply be handed. Narrowing the listing only hid the other cases; it did not put them out of reach.

The check moves to where cases are addressed — one place in Execute, before the switch. Is this credential pinned to a queue and does this call name a case, then the case is read once and its owner checked. Everything that follows inherits it: get_case, list_messages, reply, set_status, escalate, list_files, attach_file, including the ones added later. get_case reuses that read, so the wall costs no extra call for the action that would have made the same one anyway.

Three things to know before upgrading:

• search_cases is the only action without a WHERE clause. SOSL cannot filter on the polymorphic owner, so the result is narrowed after the fact. Without it, search would have been the hole.
• Naming a different queue in the call is now an error. Under a ceiling that is not a narrower request but a wider one, and the point of putting the queue in the credential is that the agent cannot widen its own reach.
• assigned no longer beats the pinned queue, it fails against it. A case owned by a queue is not owned by a user, so the two can never both hold; the previous "assigned wins" was the ceiling leaking.

The error names the actual owner rather than hiding it. Whoever hits this wall usually has the wrong case number, and "belongs to somebody else" without saying whom costs a second round trip to find out.