feat(init): connect scaffolds to a managed instance when logged in

[Bccorb]

What

seamless init now connects a scaffolded app to a managed Seamless Auth instance instead of hardwiring localhost.

Before, init set AUTH_SERVER_URL=http://localhost:5312 and API_URL=http://localhost:3000 and minted the app's API_SERVICE_TOKEN with a local generateSecret(). It never read the logged-in profile, keychain session, or instance URL, so running seamless login and then seamless init produced an app pointed at localhost. The existing-project path was an unimplemented stub.

How

When a profile has an active session (and --local is not passed), init defaults to the managed control plane:

1. Resolves the active profile and keychain session via the existing authenticated client (createAuthClient).
2. Lists the developer's applications from the control plane (GET /applications), auto-selecting a single app or prompting to choose (--app <id> skips the prompt).
3. Issues the application's service token from the control plane (POST /applications/:id/rotateServiceToken), the real credential rather than a local secret. Because the token is shown only once, it confirms before issuing a new token for an app that already has one (issuing invalidates the old one).
4. Scaffolds web + api pointed at the application's managed auth instance (domain), with no local auth server, Docker Compose, or admin dashboard.

Running init in an existing (non-empty) project wires the managed credentials into api/.env in place, preserving existing keys, or prints the values when there is no api directory. Source is never overwritten.

The self-hosted/local flow is unchanged, reachable with seamless init --local, and still used automatically when no session is present. SEAMLESS_PORTAL_API_URL overrides the control-plane host (defaults to the managed service).

Notes

• New src/core/portal.ts (control-plane client, reuses the profile's Bearer session against the portal host) and src/prompts/appSelect.ts (application selection).
• The control plane only returns a raw service token at rotation time (stored write-once), so issuing is the real credential flow. This matches the portal's own "Get connected" contract (authServerUrl = the app's domain, serviceSecret = the issued token, jwksKid default).

Testing

• npm run build and npm test pass (new unit tests for portal.ts and appSelect.ts).
• Drove the managed existing-project path end to end against a stub control plane: the token was pulled from the control plane and merged into api/.env while preserving existing keys; the no-api-dir branch printed the values; the no-session branch fell back correctly.

Closes #59