[HouMinXi]

What breaks

grok47MaxEffort.ts imported the server feature-flag module directly. The chain
that reaches a client component:

src/lib/db/core.ts            (import fs from "fs", better-sqlite3 adapters)
src/lib/db/featureFlags.ts
src/shared/utils/featureFlags.ts
open-sse/utils/cursorAgentProtobuf/grok47MaxEffort.ts
src/lib/providerModels/cursorAutoCatalog.ts
src/lib/providers/mergeProviderModelListing.ts
src/app/(dashboard)/dashboard/providers/[id]/ProviderDetailPageClient.tsx

#17388 added grok47MaxEffort.ts and wired it into cursorAutoCatalog.ts,
which did not import it before. That puts the SQLite adapters and fs into the
browser bundle, and the production build rejects the bundle on node builtins.

The change

grok47MaxEffort.ts now calls isRegisteredFeatureFlagEnabled from
open-sse/utils/registeredFeatureFlag.ts. That helper already exists for this
purpose and is what codebuddy-cn.ts and providerSafety.ts use. It reads the
resolver featureFlags.ts publishes on a process-wide symbol, so it reaches the
same answer without importing from src/.

This removes an open-sse -> src import rather than adding one.

Behaviour

The server answer is unchanged while the resolver is registered, which it is on
every DB-backed path: src/lib/db/core.ts imports featureFlags.ts, and that
module registers the resolver when it loads. instrumentation-node.ts awaits
db/core during boot, so registration happens before any request.

One side effect worth naming: reading the flag no longer forces the database
layer to load. Nothing in the tree relied on that.

With no resolver registered the helper is env-only. This flag defaults to
false, and both call sites (requestedModelParameters.ts,
cursorAutoCatalog.ts) run inside DB-backed request paths, so that branch is
not reachable there today.

Verification

• client-bundle-no-server-only-10692, the whole-graph guard, is red on the
  parent commit and names the trail above; it passes here.
• Injection, both directions: restoring the server import turns that guard red
  again and fails both assertions in the new test. Restoring the helper returns
  everything to green.
• The new test also covers what the graph guard exists for but a single-file
  read cannot see: the helper call left in place while the server import comes
  back alongside it.
• grok47-flag-client-safe-import, cursor-grok-47-context-17386,
  cursor-grok-effort-aliases, feature-flag-resolver-bridge,
  grok47-max-effort-flag, registered-feature-flag: 17/17.

CI note

Unrelated to this diff, and present on the parent commit: Change Classification fails on free-catalog-evidence: tokenharbor/claude-haiku-5.5,
which makes the downstream unit job skip, and source-scanner-guards reports
two other files. Neither is touched here.

[HouMinXi]

After syncing f75a937, this PR contains only the bridge-to-open-sse regression test and its changelog entry. The production fix is already in release/v3.8.53 through #18625.

The new test checks both sides of the shared symbol lookup. In an isolated mutation check, changing the bridge's symbol prefix made it fail while the existing tests for each side still passed.

The shared Gemini midnight-clock and VS Code catalog-discovery test fixes are tracked separately in #18748. Their targeted cases have passed in its Ready CI run; this does not establish that this PR's full checks are green.