[APPS][Connections Part 9] Refactor action catalog module scope boundary

[sdkennedy2]

Motivation

This is the first slice split out of the previous all-in-one module graph PR. Before enriching module graph records, the shared eslint-scope analysis needs to live outside the action-catalog-specific call-site logic so module graph parsing can reuse identifier resolution without depending on connection ID or action catalog concepts.

Changes

This introduces a domain-neutral ModuleScopeAnalysis helper for parsed backend ES modules. It owns the eslint-scope manager, reference lookup by identifier node, and module-scope variable lookup.

Action catalog parsing now layers ActionCatalogScopeAnalysis on top of ModuleScopeAnalysis:

export interface ActionCatalogScopeAnalysis {
    moduleScope: ModuleScopeAnalysis;
    actionFunctions: Set<eslintScope.Variable>;
    actionNamespaces: Set<eslintScope.Variable>;
}

Connection ID value extraction now receives the generic module scope analysis directly. That keeps identifier-to-definition resolution shared while leaving action-catalog call classification and connection ID value resolution as separate domain concerns.

QA Instructions

No manual QA; this is an internal AST parsing refactor covered by CI.

Blast Radius

This only affects backend apps AST parsing used to discover action-catalog connection IDs. It should be behavior-preserving: the same call-site and same-module connection ID extraction tests continue to cover the changed boundary.

Documentation

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

[sdkennedy2]

• [APPS][Connections Part 11] Resolve static definitions through module graph #374 : 2 dependent PRs (#375 , #376 )
• [APPS][Connections Part 10] Enrich parsed backend module records #371
• [APPS][Connections Part 9] Refactor action catalog module scope boundary #373 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.