Zappier + middleware composition

Composition: zappier commercial edge + Verae adapter

Users → Zapier UI
Zapier cloud runs packages/verae-zapier
  --HTTPS, x-api-key--> packages/zappier /v1/*
                          (meter, quote, 401/403, usage)
                          --internal HTTPS--> packages/verae-zapier-middleware /zapier/v1/*
                                --sync--> api.veraetime.net  or MOCK_VERAE
                                --NATS--> workers --> Verae + Zapier REST Hooks

Humans → zappier /portal   signup, API key, usage, reloads, invoices
Ops    → zappier /admin    rate card, tiers, customers, PO invoices

Ownership

Concern	Package
API keys, custom pricing, Stripe, invoices, portal	`packages/zappier`
Timestamp/verify/status, NATS, REST Hooks, mock Verae	`packages/verae-zapier-middleware`
Zapier Platform nouns (creates/searches/triggers)	`packages/verae-zapier`
Official SDK reference	`vendor/zapier-platform`

Zapier never talks to NATS or api.veraetime.net.

Do not reimplement Stripe, invoices, or the rate-card UI inside the Verae middleware.

Public keys are zappier x-api-key (issued at portal signup). Middleware zmw_ / PLAN_LIMITS stay internal until composition PR 4 removes them from the public path.

Demo zappier routes /v1/transform and /v1/storage are a metering sandbox, not Verae timestamping or encrypted LTS.

Payment invoices (zappier) are not certified timestamp receipts (Verae feature i).