feat: write the app service token as SEAMLESS_SERVICE_TOKEN

[Bccorb]

What

Applications now read their service token as SEAMLESS_SERVICE_TOKEN, the name the managed portal's snippet already uses. The auth server keeps reading API_SERVICE_TOKEN (the pinned auth API, v0.18.0, only knows that name).

• init, local stack: the generated docker-compose.yml gives the api service (or the full-stack web service) SEAMLESS_SERVICE_TOKEN. The auth service keeps API_SERVICE_TOKEN with the same value, and a comment above the app's variable says so.
• init, managed connect into an existing project: writes SEAMLESS_SERVICE_TOKEN into api/.env; the values printed when there is no api/ use the new name and mention the old one for older backends.
• add: the backend .env gets SEAMLESS_SERVICE_TOKEN, and the printed Node, Go, Rust and Python code reads it.
• verify: the Express and Fastify reference apps read SEAMLESS_SERVICE_TOKEN; the Next.js service is given both names so starters from before the rename still run. CONFORMANCE.md documents the new name. The harness's own inputs (API_SERVICE_TOKEN on the host, SEAMLESS_API_SERVICE_TOKEN for Playwright) are the auth API's secret and are unchanged.
• Help topic for add, README.

Existing projects

When a project's .env already has API_SERVICE_TOKEN and not SEAMLESS_SERVICE_TOKEN, seamless add and managed connect update API_SERVICE_TOKEN in place, print a note saying so, and (for add) print code that reads that name. They never add a second variable the app does not read. src/core/serviceToken.ts holds that rule.

Every remaining API_SERVICE_TOKEN hit is deliberate

The auth server env (buildAuthEnv, extractSharedFromExistingEnv, the seamless/ stack from add --local), the verify harness inputs, the legacy-name branch and its tests, and the docs that explain the two names.

Merge and release order

This PR goes first. It pairs with fells-code/seamless-templates#122 (the starters rename, requires.cliMin 0.24.0).

1. Merge this PR. It is safe on its own: the CLI still pins templates v0.19.1, whose starters read API_SERVICE_TOKEN from the api/.env written from their template.json, and managed connect and add keep that name for such a project. It also has to land before the templates PR, because the templates PR's conformance run uses this repo's main verify stack, and only this PR gives the Next.js service SEAMLESS_SERVICE_TOKEN.
2. Release it as 0.24.0 (minor changeset; the open version PR chore: version packages #272 becomes 0.24.0 if this lands before it is merged, otherwise 0.23.1 ships first).
3. Merge and release the templates PR.
4. Follow-up here: bump SEAMLESS_TEMPLATES_REF / SEAMLESS_TEMPLATES_COMMIT to that templates tag.

Verification

• npm run build: passes.
• npm test: 64 files passed, 1 skipped; 1333 tests passed, 4 skipped.
• npm run check:types-current, npm run check:templates-pin: pass.
• Real run with this build reporting 0.24.0 and SEAMLESS_TEMPLATES_DIR at the templates branch: init my-app --local --yes --email=you@example.com </dev/null succeeds; api/.env has SEAMLESS_SERVICE_TOKEN; docker compose config shows api: SEAMLESS_SERVICE_TOKEN and auth: API_SERVICE_TOKEN with the same value; npm run check in the scaffolded api/ passes (22 tests) and its assertEnvironment() passes on the generated .env. Without the 0.24.0 version the templates branch refuses with "requires seamless-cli >= 0.24.0".
• Same build against the pinned templates v0.19.1: the starter's api/.env API_SERVICE_TOKEN equals the compose SEAMLESS_SERVICE_TOKEN, so step 1 is safe.
• add --local --yes --skip-install on a scratch Express app: writes SEAMLESS_SERVICE_TOKEN (equal to seamless/.env's API_SERVICE_TOKEN) and prints process.env.SEAMLESS_SERVICE_TOKEN. On one whose .env already had API_SERVICE_TOKEN: updates it in place, prints the note, adds no second variable, and prints process.env.API_SERVICE_TOKEN.
• Not run: scripts/scaffold-smoke.sh (ports 5432 and 5312 are held by another local stack). It covers db and auth, which this does not change.