docs(config): correct two docstrings naming retired template variables

[worktrunk-bot]

Requested by @max-sixty in #2984 (comment) — "fix those references, add a TODO to remove the vars in 3 months".

#4080 stopped supplying the retired template variables to any renderer and moved their renames into the load-path deprecation layer. Two docstrings still described the old behavior, and there was no record of when the rename rows themselves can go.

Comment fixes

• format_path's argument doc said main_worktree "supplies both {{ main_worktree }} and {{ repo }}". refactor(config): stop supplying the deprecated template variables, migrating them on load #4080 deleted the vars.insert("main_worktree", …) line directly below it, so only {{ repo }} is supplied now.
• Command::template's doc offered {{ worktree }} as an example variable; it is retired to worktree_path.

TODO on RETIRED_VARS

Dates the removal at 2026-12-16, three months on from #4080, and records the constraint that makes the rows non-uniform: dropping a row stops the rename, so the old name has to fail loudly on its own first. A hook, alias, or worktree-path template already does, through SemiStrict expansion — but commits renders under minijinja's Lenient, which iterates an undefined value as an empty sequence, so dropping that row alone would silently empty a squash prompt's commit list. That row can only go once build_prompt rejects the name itself, which is the open question on #2984.

Comments only — no behavior change, no CHANGELOG.md entry. cargo clippy --lib --all-features, cargo fmt --check, and cargo test --lib config:: (550 tests) pass locally.

[worktrunk-bot]

test (macos) is red at this head, from an environment flake rather than
anything in the diff: test_bash_shell_integration_hint_suppressed captured
bash: child setpgid (63460 to 63460): Operation not permitted as an extra
line in its PTY snapshot. That is the macOS runner's job-control behavior
leaking into the captured session, and this PR changes only doc comments, so
it cannot reach that test. Rerunning the job.

No findings on the change itself — I checked each claim the new prose makes
against the code it describes, including that build_prompt is still the only
user-template surface rendering under minijinja's default Lenient
(wt list custom columns look Lenient-adjacent but validate_list_column_template
rejects an unknown name at resolution and aborts the command).