What problem does this feature solve?

output.codeSplitting.groups[].name can inspect the module graph through
ctx.getModuleInfo(moduleId). However, ModuleInfo.importedIds represents the
static imports discovered while loading the module, not the static dependency
edges that remain after tree shaking.

This makes it difficult to implement manual chunking policies based on the
post-tree-shake reachability graph. For example:

// entry.js
import { feature } from './feature.js';

if (BUILD_FLAG) {
  feature();
}

When BUILD_FLAG is statically replaced with false, Rolldown can tree-shake
the import and exclude feature.js. A custom chunking policy may still need to
walk the dependency closure rooted at entry.js, for example to keep initial
modules in a stable chunk. Walking ctx.getModuleInfo('entry.js').importedIds
still traverses feature.js, even though the edge is no longer part of the
included output graph.

The chunking pipeline already computes the graph needed for this:

• The link stage runs include_statements() and then
  patch_module_dependencies():
  https://github.com/rolldown/rolldown/blob/v1.0.0-rc.17/crates/rolldown/src/stages/link_stage/mod.rs#L206-L219
• Code splitting uses the resulting meta.dependencies and checks
  meta.is_included while computing reachability:
  https://github.com/rolldown/rolldown/blob/v1.0.0-rc.17/crates/rolldown/src/stages/generate_stage/code_splitting.rs#L952-L989
• Dynamic group names currently receive a ChunkingContext backed by the
  scan-time module info map:
  https://github.com/rolldown/rolldown/blob/v1.0.0-rc.17/crates/rolldown/src/stages/generate_stage/manual_code_splitting.rs#L179-L182

Exposing the post-tree-shake dependency view to chunking callbacks would allow
custom grouping logic to make decisions against the same graph Rolldown uses
for chunk reachability.

What does the proposed API look like?

One option is to add a chunking-specific method:

interface ChunkingContext {
  getModuleInfo(moduleId: string): ModuleInfo | null;
  getIncludedImportedIds(moduleId: string): string[];
}

An alternative is to add chunking-specific metadata to the module info returned
by ChunkingContext:

interface ChunkingModuleInfo extends ModuleInfo {
  includedImportedIds: string[];
  isIncluded: boolean;
}

interface ChunkingContext {
  getModuleInfo(moduleId: string): ChunkingModuleInfo | null;
}

I would prefer preserving the existing meaning of ModuleInfo.importedIds for
Rollup compatibility and exposing the post-tree-shake graph separately.

The implementation may be able to reuse the LinkStageOutput.metas
dependencies that determine_reachable_modules_for_entry() already traverses,
rather than recomputing graph inclusion in JavaScript.