fix(hooks): expand everything but vars.* in a preview

[max-sixty]

Follow-up to #3635, from two reviews that landed after it merged.

The vars.* preview was worse than #3635 claimed

render_template_preview short-circuits on template_references_var(template, "vars"), returning the raw template. So one vars. token disabled expansion for the entire command:

pre-commit = "deploy --branch={{ branch }} --repo={{ repo }} --env={{ vars.env }}"

before:  deploy --branch={{ branch }} --repo={{ repo }} --env={{ vars.env }}
after:   deploy --branch=main --repo=repo --env={{ vars.env }}

#3635 described this as "a vars.* template renders raw", which is true but understates it: {{ branch }} and {{ repo }} stopped expanding too, in a command whose whole job is to show the expansion. That short-circuit predates #3635 and has been degrading wt hook <type> --dry-run the same way; #3635 only extended it to wt hook show --expanded.

The fix is at the source rather than at either caller. A preview now injects a stand-in object for vars that renders each reference back as itself, nested access included ({{ vars.config.port }} round-trips), while every other variable expands normally. VarsMode::Resolve keeps execution reading real values from git config; only previews pass VarsMode::Literal. A preview also no longer spawns the git read that resolving vars required.

vars.* stays literal on purpose: those values are read when the step runs, after an earlier step in the pipeline may have written them, so a value resolved at preview time can differ from the one the run uses.

Nothing covered this, which is why the suite stayed green through the regression. test_hook_show_expanded_matches_dry_run now sets a var and asserts the listing and the dry-run both leave it alone while expanding {{ branch }} beside it.

The syntax gate is a type error now

#3635 moved the template syntax check out of prepare_steps into a free validate_pipeline_syntax that both execution funnels had to remember to call. prepare_steps now returns a PreparedPipeline the caller must resolve: .validated() for the paths that run hooks, .into_unvalidated() for the listing, which annotates a broken template in place rather than blanking itself. Forgetting is a compile error, the same property ApprovedHookPlan gives hook approval.

Smaller items

Four cross-references went stale when the syntax check moved: PreparedCommand.template, validate_template_syntax, the switch.rs skip comment, and HOOK_INFRASTRUCTURE_VARS (which still named two deleted functions). The --expanded behavior is now documented in the sentence that already owns {{ vars.<key> }} semantics, with its three generated mirrors regenerated.

PreparedStep::commands() replaces two hand-rolled matches in hooks.rs. default_branch moves inside build_manual_hook_template_vars — only the commit-hook arm reads it, and resolving it can cost a git ls-remote on a fresh clone, so the other eight hook types no longer pay for it. The listing carries its expansion state in an Option<String> instead of re-deriving "was this expanded?" from whether a context exists.

This was written by Claude Code on behalf of max

[worktrunk-bot]

Two stale references to validate_pipeline_syntax slipped in — the same class of stale cross-reference this PR set out to fix, except here they point at the function the PR removes. Both should name PreparedPipeline::validated, the path that now runs the check. Suggestions inline. Otherwise the change reads clean: the LiteralVars stand-in round-trips nested access, the VarsMode split keeps execution reading real values, and the #[must_use] PreparedPipeline gate is a nice unforgeable-by-construction property.