proto: a flexiq.admin.v1 service

flexiq.v1.ProducerService covers submit, read, cancel and count. flexiq.executor.v1 covers
claiming and reporting work. Between them there is no way, over the network, to:

• pause or resume a queue
• list the dead-letter queue, inspect an entry, or replay one
• list workers, drain one, or read heartbeats
• create, update, delete or trigger a periodic task
• read or change a rate limit or a concurrency cap
• read queue and predicate stats beyond the counts the producer door exposes

The dashboard does all of these, so the logic exists — it is just not on the wire. Today the
only automation path is to drive the dashboard's HTTP API, which is not a contract, or to embed
an SDK, which needs one of three languages and a database connection.

Add flexiq.admin.v1 as a third service on the same listener, with its own scope (see #839).

Design constraints, from #710:

• Not a Storage proxy. ~110 trait methods with a three-backend parity obligation each.
  Expose operations an operator performs, named as operations. The settings KV in particular
  must not become a generic remote key-value door.
• Every RPC namespace-scoped, like everything else on the door.
• Destructive operations are explicit. Replaying a dead letter and draining a worker change
  the running system; they need their own scope, not produce.

Do the proto design as its own step and get it reviewed before the tonic impl — a wire mistake
here is permanent under buf breaking with WIRE_JSON.

Start by reviewing the existing flexiq.v1.ProducerService and flexiq.executor.v1 contracts, along with the design constraints in #710 and scope in #839. Define the namespace-scoped flexiq.admin.v1 operations, get the proto design reviewed before the tonic implementation, and verify it with buf breaking and WIRE_JSON.