Bind each customer to a Verae userId for hop tracing

Signup registers/binds a Verae central user and stores veraeUserId. Public access stays the zappier API key. Chain JWTs stay server-side behind tokenRef. Authz, billing, and jobs.watch carry veraeUserId.

packages/zapier-user-docs/02-signup-zappier-portal.md

@@ -7,6 +7,7 @@ You need an API key **before** you can connect Zapier.
 3. Enter name, email, and a password of at least 8 characters.
 4. You start on the **Free** plan and receive an **API key immediately**.
 5. Copy the key. It is sent as `x-api-key` on every Zapier request.
+6. Signup also **registers you on Verae central** and stores a stable `veraeUserId` on your account. That id rides every internal hop (billing, authz, job watch) so CS/sales and the chain can see the same person. You never paste the Verae JWT into Zapier — that token stays on the server (`tokenRef` on NATS).
 
 If your company already created an account (you received a key by email), sign up with the **same email**. The existing plan and key are kept; your password is attached to that account.
 

packages/zapier-user-docs/12-security.md

@@ -4,6 +4,7 @@
 - NS1 `nats-server` stays on **127.0.0.1:4222**. Operators use `scripts/nats-tunnel.sh`; it is not a public bind.
 - File bytes and private metadata never go on chain. Private metadata is only on authenticated archive replies.
 - API keys are `x-api-key` / Bearer tokens on HTTPS. Treat them like passwords; regenerating kills old Zaps.
+- The Verae central JWT from `/auth/login` is **not** your Zapier/portal token. Middleware holds it (or re-logins via `tokenRef`). `veraeUserId` is the public correlation id (`vu_…`).
 - Bloom filters are **not** an access-control list. On a hit, middleware still checks tenant/share before returning private records.
 
 If a trace (simulator or `DEBUG_VERAE`) ever shows a `zapier-platform-app` hop with a `verae.*` subject, that is a bug — do not push the app.