Node selection for `compile` (filter compiled output to selected actions)

[ihistand]

Summary

sqlanvil compile (and compile --json / --dot) always emits the entire compiled graph. There is no way to ask the CLI for the compiled SQL of a single model (or a subset) the way --actions / --tags already work for run.

Add the existing selection flags to compile so the output can be filtered to just the action(s) of interest:

sqlanvil compile --actions my_model --json
sqlanvil compile --tags daily --include-deps --json

This mirrors dbt compile --select my_model — a common workflow for inspecting the rendered SQL of one model without scrolling the whole graph or post-processing JSON with jq. It fits SQLAnvil's CLI-first / AI-driven positioning: pulling one model's rendered SQL into context cleanly.

Scope

This is output filtering, not partial compilation. The whole project must still compile — ref() resolution and the dependency graph require every action to be registered. We compile fully, then prune the compiled result before printing.

Implementation

All the pieces already exist:

• prune(compiledGraph, runConfig) in cli/api/commands/prune.ts — already used by run/build with identical selection semantics (actions, tags, includeDependencies, includeDependents).
• The selection flags are defined as reusable yargs options in cli/index.ts (actionsOption, tagsOption, includeDepsOption, includeDependentsOption). The include-deps/include-dependents options already validate that they only apply alongside --actions/--tags.
• The compile handler already separates compilation from output (compiles, then calls printCompiledGraph() which handles --json/--dot). Pruning slots cleanly in between.

Steps:

1. Add actions, tags, include-deps, include-dependents to the CompileArgv interface.
2. Attach the existing flag-option objects to the compile command's yargs builder.
3. In the handler, when any selector is present, run the compiled graph through prune() before printCompiledGraph().
4. In --watch mode, apply the same prune on each recompile.

No proto changes — RunConfig is already the right shape.

Decisions

1. Compile errors from unselected actions — keep graph-level/compile errors as-is. Compilation is all-or-nothing: a compile error means there is no CompiledGraph to prune, so there is nothing to selectively suppress. Compile fully, prune the result.
2. Selector matches nothing — mirror whatever run currently does for an empty prune result (emit an empty graph) for consistency rather than introducing new error behavior.