deploy: a Terraform provider for queues, periodic tasks and tokens

Everything about a FlexiQ deployment is imperative today. Queues are created by use. Periodic
tasks are defined in application code. API tokens are minted by running a CLI subcommand and
copying the output, once, by hand.

None of that survives contact with an infrastructure team. The token in particular is a
credential created by a human at a terminal and pasted into a secret store — the exact workflow
every platform team is trying to delete.

A Terraform provider makes them resources:

• flexiq_queue — name, concurrency cap, rate limit, on_excess behaviour
• flexiq_periodic_task — schedule, task name, arguments, enabled
• flexiq_token — name, scopes, namespace, expiry; the secret in state, marked sensitive, so it
  reaches a secret store without a human seeing it
• flexiq_namespace — with its quotas, once those exist

Hard dependency: the admin service (#836). A provider needs read-your-writes on every
resource it manages, and today the wire cannot even list a periodic task. Do not start the
provider before the RPCs it reads exist — a provider built on the dashboard's HTTP API is built
on something that is not a contract.

Token rotation deserves design attention, not a create_before_destroy and hope: expiry is
mandatory (90 days default, 365 max), so every flexiq_token resource is a thing that expires
under Terraform's feet.

Start with the admin service in #836 and its RPC contract; the issue says the provider must wait until the managed resources can be read back, including periodic tasks. Define the provider scope for queues, periodic tasks, tokens, and namespaces, with token expiry and rotation behavior decided before implementation; done means these resources use the contracted admin API.