auth: token scopes beyond produce and execute

crates/flexiq-server/src/tokens/scope.rs defines two scopes. --scope produce opens
flexiq.v1 — submit, read and cancel. --scope execute opens flexiq.executor.v1. They are
deliberately not a hierarchy, which is right: a worker that can poll must not be able to enqueue.

Two bits is not enough to express the things people actually need:

• Read-only. A dashboard, an alerting job or a support tool that must see jobs and must not
  submit or cancel them. Today that is produce, which grants cancel.
• Per-queue. A token that may enqueue to emails and not to billing. Today a token
  reaches every queue in its namespace.
• Per-task. A token that may enqueue exactly send_receipt. This is the shape a webhook
  receiver or an untrusted edge service wants.
• Admin, separately. Whatever flexiq.admin.v1 (#836) needs must not fall under produce.

Constraints:

• the namespace binding at mint time does not change and does not weaken. This is authorization
  within a namespace.
• ScopeSet is a bitset today (ScopeSet::ALL, ScopeSet::NONE, Scope::names()). Per-queue
  and per-task are not bits — they are a resource pattern. That is a model change, not a new
  enum variant, and the token row, the CLI (crates/flexiq-server/src/tokens/cli.rs), the
  dashboard's token UI and the interceptor all move together.
• a gate must not fail open. An unrecognised or unparseable scope pattern denies.
• existing tokens must keep working, with their current grants, across the migration.

Start with crates/flexiq-server/src/tokens/scope.rs and trace how ScopeSet and Scope::names() reach the token row, crates/flexiq-server/src/tokens/cli.rs, the dashboard token UI, and the interceptor. Define the resource-pattern model and migration behavior before changing each integration. Done means read-only, per-queue, per-task, and separate admin authorization work without weakening namespace binding, fail closed, and preserve existing token grants.