Add the client half of the auth provider contract with generated wiring

[FranjoMindek]

Description

Stack 7/8 (between adapter codegen and the packages). The client half of the auth provider contract, landing together with its generated consumers.

The problem it solves: client integration was the design's weakest part — hand-written App.tsx glue per app, a push-based token bridge with a staleness window across Clerk's ~60s rotations, and logout() that didn't tell the provider's client.

• Contract (@wasp.sh/auth-contract/client): ClientAuthAdapter { Wrapper?, getCredential(), onCredentialChange?, onLogout? } + WaspClientRuntime + ClientAdapterFactory. getCredential is pull-based on purpose (asked at each request, rotating tokens always current) and doubles as the readiness gate (resolves only once the provider's client is loaded).
• Manifest: client: { package } entry, mapped to IR clientPackage — consumed this time, unlike its earlier deleted incarnation.
• Generated wiring: a wasp/client/auth/provider module instantiates createClientAdapter(runtime, options) with the manifest-validated client env; WaspApp composes Wrapper around the app (outside rootComponent); the api client's beforeRequest awaits getCredential() instead of reading stored state; logout() calls onLogout(); credential changes rebroadcast into the existing sessionId events so query invalidation and websockets react for free.

No package implements it in this PR (the shape is final; consumers of the factory arrive one PR later, same pattern as the server half in the previous PR).

Review guidance: the contract file and the generated provider.ts template are the substance; the api/logout/WaspApp edits are small conditional branches, inert for every app without a client adapter (kitchen-sink goldens prove it).

Type of change

• 🔧 Just code/docs improvement
• 🐞 Bug fix
• 🚀 New/improved feature
• 💥 Breaking change

Checklist

• I tested my change in a Wasp app to verify that it works as intended.

• 🧪 Tests and apps:

  • I added unit tests for my change.
  • (if you fixed a bug) I added a regression test for the bug I fixed.
  • (if you added/updated a feature) I added/updated e2e tests in examples/kitchen-sink/e2e-tests.
  • (if you added/updated a feature) I updated the starter templates in waspc/data/Cli/templates, as needed.
  • (if you added/updated a feature) I updated the example apps in examples/, as needed.
    • (if you updated examples/tutorials) I updated the tutorial in the docs (and vice versa).

• 📜 Documentation:

  • (if you added/updated a feature) I added/updated the documentation in web/docs/.

• 🆕 Changelog: (if change is more than just code/docs improvement)

  • I updated waspc/ChangeLog.md with a user-friendly description of the change.
  • (if you did a breaking change) I added a step to the current migration guide in web/docs/migration-guides/.
  • I bumped the version in waspc/waspc.cabal to reflect the changes I introduced.

[cloudflare-workers-and-pages]

Deploying wasp-docs-on-main with    Cloudflare Pages

Latest commit:	ad3d5c4
Status:	✅  Deploy successful!
Preview URL:	https://989639a8.wasp-docs-on-main.pages.dev
Branch Preview URL:	https://franjo-auth2-client-adapter.wasp-docs-on-main.pages.dev

View logs

[pkg-pr-new]

Open in StackBlitz

@wasp.sh/spec

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/spec@4732

@wasp.sh/wasp-cli

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli@4732

@wasp.sh/wasp-cli-darwin-arm64-unknown

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-darwin-arm64-unknown@4732

@wasp.sh/wasp-cli-darwin-x64-unknown

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-darwin-x64-unknown@4732

@wasp.sh/wasp-cli-linux-arm64-glibc

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-linux-arm64-glibc@4732

@wasp.sh/wasp-cli-linux-x64-glibc

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-linux-x64-glibc@4732

@wasp.sh/wasp-cli-linux-x64-musl

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-linux-x64-musl@4732

commit: ad3d5c4

[github-actions]

This pull request is now stale.
That means that it hasn't seen any activity for a while, and needs to be updated or addressed before it can be merged.

Next steps if the PR is still relevant, and you are able to devote time to it:

• If you received any questions or feedback, please address them.
• Merge the latest main into your branch to ensure that you are up to date.
• If you are still working on the changes, please leave a comment telling us so.
• Otherwise, just leave a comment explaining why the PR is still relevant.

If no action is taken, this PR will be automatically closed in 7 days.