feat: non-interactive seamless init --yes with full flag coverage

[Bccorb]

Problem

seamless init cannot be run non-interactively. The only inputs it accepts are --local,
--app, --profile, and the template alias flags. Email, auth mode, and admin mode
(src/prompts/projectSetup.ts) have no flag form at all, and
neither does the local-vs-managed choice when a portal session exists.

That rules out CI, Dockerfiles, scripted demos, and any agent that has not allocated a pty.
The current workaround is an expect script, which requires knowing the prompt order, which
requires reading the source.

This is the highest-value item on the list: it is what turns the CLI from "needs expect" into
one line in a Dockerfile.

Change

Add --yes (-y) plus a flag for every prompt, each defaulting to the option already marked
(recommended):

flag	prompt it replaces	values	default
--web=<id|alias>	Web example	registry web templates	react-vite
--api=<id|alias>	Backend framework	registry api templates	express
--email=<addr>	Your email (becomes the admin)	any address	required under --yes
--auth=<docker|local>	How would you like to run SeamlessAuth?	docker, local	docker
--admin=<api|image|source|none>	How to host the admin console	those four	api

Rules:

• --yes means "do not prompt". Any question that cannot be answered from a flag or a safe
  default fails with a message naming the missing flag, rather than blocking on a prompt.
• --email has no safe default. Under --yes it is required unless a portal session supplies
  one (getPortalSession()?.email, which already seeds the prompt's initial value).
• Each flag is honored with or without --yes. Passing --admin=none interactively just
  skips that one question, the way the template flags already skip theirs.
• Managed vs local stays explicit: --local or --app <id>. Under --yes with a portal
  session and neither flag, error instead of guessing, since that choice decides where the
  project's auth lives.
• --yes does not confirm the overwrite. The non-empty-directory confirmation in
  src/prompts/initMode.ts is the one destructive prompt in the
  flow, and its comment is explicit that the hint is not consent. It gets its own opt-in
  (--force), so a broad "assume yes" can never be the thing that writes over someone's
  work. Under --yes without --force a non-empty directory is a hard error.
• Invalid values list the valid ones. Values are validated against the fetched registry for
  --web / --api, so the error names real templates.

Note that --admin=source is currently broken (#82) and --auth=local is not really
honored (#92). Adding flags for them does not fix those; keep the flags aligned with whatever
those issues settle on.

Acceptance

• seamless init demo --local --yes --email=you@example.com scaffolds end to end with no
  prompt, on a pty and on a plain pipe alike.
• The same command with --web=react-oauth --api=fastify --auth=docker --admin=api selects
  exactly those.
• --yes with no --email and no portal session errors naming --email.
• --yes in a non-empty directory errors and names --force; adding --force proceeds.
• --yes with a portal session but neither --local nor --app errors.
• Help for init documents every flag and its default.