chore: version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

seamless-cli@0.16.0

Minor Changes

• b9529c6: seamless init learns the mobile template kind.

  seamless-templates gains a third kind next to web and api, starting with an Expo (React
  Native) starter. The CLI treated an unknown kind as if it were not there: the alias resolver
  skipped it, the prompts never offered it, and verify filtered it out without a word.

  A mobile starter is optional. init asks "Mobile app" after the backend, defaulting to none;
  --mobile=<id|alias> (or the bare alias, --mobile / --expo) includes one; --yes scaffolds
  without, since a native app brings prerequisites (an associated domain for passkeys) an
  unattended run should not opt into; and a registry that predates the kind offers nothing, so
  there is no question to ask. A chosen starter lands at mobile/ with its .env filled from the
  manifest, is recorded as services.mobile in seamless.config.json, is checked by seamless check only when recorded, and is called out in the success output with how to start it and the
  Android emulator host. verify announces the mobile templates it cannot drive instead of
  filtering them silently. Template copying skips .expo, ios, and android.

  The templates registry pin moves to the release that carries the starter in a follow-up.

Patch Changes

• 4bbf7ac: seamless verify --local packs @seamless-auth/client alongside @seamless-auth/react
  when the React SDK checkout is an npm workspace.

  The client SDK repo is becoming a workspace that publishes a framework-agnostic
  @seamless-auth/client next to @seamless-auth/react, and the react tarball depends on
  the client one. Packing only the root of such a checkout would produce the private root
  package, and installing the react tarball alone would go to the registry for a client
  version that is not published yet. The harness now reads workspaces from the checkout's
  package.json, packs both packages when it finds one, and the react image installs every
  tarball in one npm install so the dependency resolves from the sibling file. A checkout
  that predates the workspace is packed as before. The version line reported for
  @seamless-auth/react reads the react package's own manifest in a workspace.