Motivation

Backend connection ID extraction already walks reachable app-local modules, but it only supported inline and same-module values. Real apps often keep connection IDs in shared modules and import them into backend helpers. This PR wires the generic static string resolver into module-graph connection ID extraction so those imported values can be analyzed conservatively.

Changes

Module-graph extraction now uses each reachable ParsedModuleRecord directly instead of reparsing through the same-file-only extraction path. For each action-catalog call, the connection ID adapter passes the full connectionId expression to:

resolveStaticStringValue(modules, record.id, connectionIdExpression)

Resolved strings are added to the conservative backend-file allowlist. Unsupported results fail closed using the existing connection ID error path while preserving the generic unsupported reason and message for diagnostics.

This broadens supported connection ID shapes to imported constants, imported static templates, imported const chains, imported object roots, nested static object paths, local export aliases, named re-exports, import/export relays, and unambiguous star exports. Default imports, namespace imports, ambiguous star exports, missing exports, mutable or reassigned bindings, cycles, and dynamic expressions remain unsupported and fail closed.

QA Instructions

Review extract-connection-ids-from-module-graph.test.ts for the imported constant, const-chain, object-path, re-export, star-export, and unsupported-case coverage. The stack remains conservative: unsupported imported or dynamic forms throw instead of silently omitting a possible connection ID.

Blast Radius

This affects backend manifest connection ID extraction for reachable app-local backend modules. It does not change module collection, graph walking, upload plumbing, dev middleware, or the manifest schema.

Documentation

• How to reliably make frontend production changes
• PR Description Guidelines
• Deploy steps