docs: cut internals, edge-case mechanics, and deprecated behavior

[max-sixty]

Follows #4153, which cut two wt config update paragraphs describing internals and deprecated behavior. This sweeps the rest of the docs for passages of the same kind: how a command is implemented, edge cases the command already reports with an error or warning when they happen, and deprecated or removed behavior. The edits are to the help text in src/cli/*.rs and the non-command docs pages; everything else in the diff is regenerated (command pages, skill mirrors, help snapshots, dev/*.example.toml).

What went, by kind:

• Deprecated or removed: the wt hook --var paragraph and its row in the extending guide's hooks-vs-aliases table; the page for the hidden wt config state ci-status subcommand; the approved-commands sentence in user config (now about pattern keys in approvals.toml); the "retired wrapper" wording in the "shell wrapper is out of date" warning.
• Internals: wt step diff's "How it works"; copy-ignored's background-priority section and WORKTRUNK_FOREGROUND; promote's rename(); the three env vars marked "Internal:" in the config page's table; how the OpenCode plugin loads; skim query operators in the picker; the --prs log tab's data source.
• Edge cases the command reports itself: post-commit hooks skipped when wt merge removes their worktree; a branch retained because a second worktree has it checked out (the FAQ keeps this); a registered worktree whose directory is gone and rollback races in wt step push; template errors in for-each; .bak-2 backup names in relocate.
• Mechanics a user doesn't act on: measuring against the upstream when the local default branch lags (wt merge, wt step rebase, wt list); default-branch cache internals other than the rule that a guess made during an outage isn't cached; the statusline pace forecast and cell-dropping rules; the FAQ's fsmonitor and shell-install migration detail, trimmed down to the facts; the "Three things to get right" list for agent CLIs without a plugin; the wt up recipe's guard explanations, condensed to the two details that matter when adapting it.

A few label-then-colon-then-link sentences ("How the fragment renders: [the LLM commits guide]") are rewritten as sentences. The built-site test's heading count for the config page's table of contents drops from 33 to 32 with the ci-status section gone.

Kept on purpose: the "Local CI" section, the homepage, the FAQ's lists of files Worktrunk creates and deletes, the warning that post-* hooks from user and project config can race, the direct git config marker example, wt remove's notes on the capped default-branch walk and what "target" means (the command reports neither), the troubleshooting entry for the retired template-file keys (the unknown-field warning doesn't name the replacement), and the wt list "Schema 1" mapping table (json-schema = 1 is still supported without a deprecation warning).

This was written by Claude Code on behalf of max-sixty

🤖 Generated with Claude Code

[worktrunk-bot]

Three inline suggestions, plus two points that need a decision rather than a fix.

troubleshooting.md: the retired template-file keys lose their only migration path. Most of these cuts hold up because the command already says the thing itself — dropping the post-commit-skipped paragraph is safe because report_dropped_pipelines prints Skipped post-commit: … — worktree removed @ <path> followed by a To run commands in a worktree before it is removed, use pre-remove hint. This cut doesn't have that backstop. A config still carrying commit.generation.template-file gets the generic … has unknown field commit.generation.template-file (will be ignored) from src/config/deprecation.rs, and the custom prompt silently reverts to the built-in default. Nothing in that message names template as the replacement, and with this entry gone the instruction to paste the file's contents inline survives only in the 0.76.0 changelog. Worth keeping the entry until the key is old enough that nobody is still carrying it.

The wt remove cap paragraph collides with #4100. This PR deletes The default-branch walk is capped so a single check stays fast; a squash merge with hundreds of commits landed since the merge point falls outside the cap and needs -D to remove.; #4100 rewrites that same line in place to describe its new oldest-first path scan. Whichever merges second gets a conflict, and if this one goes first, #4100's doc update has no paragraph left to edit. That overlap is also an argument for keeping something there: the cap is the answer to "why won't this squash-merged branch delete", and the only thing the command reports is retained_unmerged.