feat: connect Tiny through its v3 API with OAuth

Tiny v3 replaces the v2 token adapter. An operator connects Tiny once from
the Kanban; the callback is authorised by a single-use state, because Tiny's
cross-site redirect does not carry the SameSite=Strict operator cookie.
Tokens are kept in provider_tokens, the refresh token rotates under a row
lock, and the worker keeps the connection alive while order creation is off.

Orders find or create the customer's contact by CNPJ, then POST /pedidos
with product ids from TINY_PRODUCT_TEXTIL_FOLHA, _TEXTIL_AVULSA, _UV_FOLHA
and _UV_AVULSA and numeroOrdemCompra DTF-<number>; a retry searches the
customer's recent orders for that number first. The product settings avoid a
_FILE suffix, which the secrets loader reads as a secret file path.

Production passes the application credentials through but keeps
TINY_ADAPTER fake: Tiny has no sandbox, so creating real orders waits for a
supervised test. compose.providers.yaml gives the local API and worker an
internet route for provider testing; the default local stack still has none.

Verified with the full CI integration sequence locally, including the new
tiny_oauth_test against the real database.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

compose.providers.yaml

@@ -0,0 +1,16 @@
+# Provider sandbox testing only: gives the API and worker a route to the
+# internet so they can reach Mercado Pago and Tiny. The default local stack
+# keeps them on an internal network with no external route, which is what
+# every other local run should keep doing.
+#
+#   docker compose -f compose.local.yaml -f compose.providers.yaml up -d --wait
+#
+# Credentials go in .env (see .env.example); never production credentials.
+services:
+  api:
+    networks: [local, provider-egress]
+  worker:
+    networks: [local, provider-egress]
+
+networks:
+  provider-egress: {}