Adds Hexclave* aliases for the user-facing Stack* exports (apps, provider, handler, theme, useStackApp, config) in packages/template; codegen propagates them to the generated SDKs. Additive and non-breaking. PR 1 of the Hexclave rebrand (see RENAME-TO-HEXCLAVE.md, Tier 1).

…ery param

Source-of-truth schema in apps/backend/.../oauth/authorize/[provider_id]/route.tsx changed: stack_response_mode lost its .default("redirect") (resolved manually now: hexclave_response_mode ?? stack_response_mode ?? "redirect"), and hexclave_response_mode was added. The OpenAPI JSON is generated from the schema; this brings the committed artifacts in sync. Fixes the 'Check for uncommitted changes' CI step.

…rs in snapshots

Two fixes for PR #1475 CI:

1. Snapshot serializer hides x-hexclave-known-error and x-hexclave-actual-status
   alongside the already-hidden x-hexclave-request-id. These carry identical
   values to their x-stack-* counterparts (dual-emit), so hiding the duplicates
   keeps existing snapshots stable instead of forcing a suite-wide regen.
   Resolves the bulk of E2E snapshot mismatches.

2. Vercel Agent review comment: response_mode fields (both stack_ and hexclave_
   variants) carry .meta({ openapiField: { description } }) documenting the
   runtime default behavior ('redirect' if neither set), which the manual
   ?? resolution at the use site applies. OpenAPI docs regenerated to reflect
   the descriptions.

…-aware default delete, dual-write coverage

Four root causes of the E2E Fallback Tests (Node 22.x) failures in PR #1475:

1. auth-like.test.ts: 4 tests asserted /^Bearer\s+stackauth_.+/, but the SDK now
   emits the new hexclave_ prefix. Regex updated to accept either prefix.
2. cookies.test.ts 'roundtrip ... encode/decode' (line 319): called the singular
   clientApp._getCustomRefreshCookieName(domain), which the cookie agent had
   removed as 'orphaned' (the check missed e2e callers). Restored the singular
   _getCustomRefreshCookieName and _getRefreshTokenDefaultCookieNameForSecure
   as back-compat wrappers returning the legacy stack-* name.
3. cookies.test.ts 'should set refresh token cookies for trusted parent domains'
   (line 184): defaultCookieName was never deleted because the default-cookie
   cleanup in _queueCustomRefreshCookieUpdate used the server-side
   setOrDeleteCookie unconditionally, even on the browser context where the
   surrounding code uses setOrDeleteCookieClient. Made the cleanup
   context-aware to match the setCookie helper above it.
4. cookies.test.ts 'should eagerly create cross-subdomain cookie on construction'
   (line 424): _ensureCrossSubdomainCookieExists skipped writing if ANY custom
   cookie name was present. With dual-write, deleting just one (as the test
   does) left the other and skipped the eager recreation. Changed .some() to
   .every() so a missing legacy-name cookie still triggers the dual-write.

…n docker entrypoint

Two review-pass fixes:

1. Authorization header emission. `getAuthorizationHeader()` is a documented
   public SDK API; its return shape (`Bearer stackauth_<base64(...)>`) is part
   of the wire contract. PR 1 is the invisible compat layer, so the emitter
   must keep emitting `stackauth_` — the parser already dual-accepts both
   prefixes for inbound. The visible flip to `hexclave_` happens in PR 2.

2. Docker entrypoint URL env mirror. The dashboard bundle inlines BOTH
   `process.env.NEXT_PUBLIC_HEXCLAVE_<X>` and `process.env.NEXT_PUBLIC_STACK_<X>`
   as sentinel literals, then resolves them via `HEXCLAVE_X ?? STACK_X` at
   runtime. The sentinel-replace loop only substitutes a sentinel when the
   matching env var is set, so a self-host that configures only one of the
   names would end up with the unreplaced sentinel string in the other slot —
   and `??` would pick the truthy sentinel literal instead of the real URL.
   Mirror the URL trio (API_URL, DASHBOARD_URL, SVIX_SERVER_URL) HEXCLAVE↔STACK
   before sentinel-replace so both names resolve to the same real value
   regardless of which name the operator chose.

…ename

Two test-only fixes for failures introduced by the wire compatibility
layer. The production behavior is correct in both cases; only the
assertions needed to catch up.

1. backend-helpers.ts OAuth authorize assertion

   The OAuth authorize route now emits two Set-Cookie headers
   (stack-oauth-inner-* and hexclave-oauth-inner-*, per cookie
   dual-write). The previous regex was anchored to '^stack-oauth-inner-'
   and matched against headers.get('set-cookie'), which joins multiple
   Set-Cookie headers with ', ' — ambiguous because cookie values
   contain ', ' inside Expires=. After dual-write the joined string also
   starts with 'hexclave-oauth-inner-…', so the anchor never matched.

   Switched to getSetCookie() (already used in helpers.ts:130) to get a
   proper array, filter for oauth-inner cookies, and shape-match each
   one. Accepts either prefix so the test stays correct across the full
   rename lifecycle (stack-only → dual → hexclave-only). This single
   helper is called from ~17 e2e files, so it accounts for ~92 of the
   96 vitest failures.

2. cli-auth-confirm.test.tsx storage key

   Production code in cli-auth-confirm.tsx was straight-renamed from
   'stack-cli-auth-confirmed' to 'hexclave-cli-auth-confirmed' (no
   dual-write — same-bundle sessionStorage key, old/new can't coexist
   in one browser session). The test wasn't updated and read the old
   key, getting null. Accounts for the remaining 4 failures (one per
   SDK package via generate-sdks fan-out).

…-write

Previous push (3f51ed5) cut e2e failures from 96 → 20. The remaining
20 came from three distinct shapes the first pass missed; all are
test-only fixes for already-correct production behavior.

1. authorize.test.ts:39,48 — two duplicate copies of the same
   stack-oauth-inner-* set-cookie regex assertion that lived in the test
   file instead of backend-helpers. Switched to getSetCookie() with the
   prefix-tolerant regex (same fix shape as backend-helpers.ts:803).

2. snapshot-serializer.ts — extended the existing 'hide dual-emitted
   hexclave-* duplicates' strategy from headers to cookies. The
   hideHeaders list already filters x-hexclave-{request-id,known-error,
   actual-status} so dual-emit doesn't bloat every response snapshot
   in the suite; the cookie path missed the equivalent treatment, so
   every OAuth response snapshot was picking up an extra
   <deleting cookie 'hexclave-oauth-inner-*'> line. Added a
   hiddenSetCookieNamePrefixes list and pre-filter the Headers'
   Set-Cookies before nicify recurses. WeakSet guards against
   infinite recursion on the filtered copy.

3. internal/projects.test.ts — two inline snapshots were regenerated
   by commit 4b16cc5 with x-hexclave-known-error visible, before
   that header name was added to the serializer's hideHeaders list
   (lines 36-37). The serializer correctly hides it now, so the
   snapshot entries are over-inclusive. Removed the two
   x-hexclave-known-error lines so the snapshots match what the
   serializer emits.