Reduce redundant asdf and Homebrew inspections

[vwall]

Summary

Reduce redundant inspection work without reusing stale state during mutations:

• Share asdf --version and asdf plugin list --urls within one planning build; per-plugin installed-version queries remain live.
• Keep public ASDF resources and apply checks fresh. Each new planning build creates its own inventory; cancellation is honored and never cached.
• Use package-targeted Homebrew outdated checks in uncached apply/upgrade resources, including casks. Normal planning retains batched inventories.
• Preserve targeted inspection errors even with partial output. Exit 1 without package output now fails instead of silently reporting an up-to-date package.

Closes #6.

Evidence

Counting-runner regressions verify:

• 30 installed asdf plugins: 90 commands before, 32 planning commands after. A second plan fetches fresh inventory; uncached inspection still uses 90 fresh commands.
• 30 Homebrew formulae or casks: 60 fresh inspection commands, all package-targeted; no global outdated scans during those rechecks. The reduction is in inventory scope, not subprocess count.

Read-only local measurements (not production guarantees):

Check	Before	After
CLI status for two installed asdf plugins, median of five runs	121 ms	65 ms
Three installed Homebrew formula outdated checks, median of three repetitions	802 ms (repeated global scans)	715 ms (targeted queries)

Homebrew timing disabled auto-update and analytics; no upgrades or installations were run.

Verification

• make release-check: formatting, full tests, vet, build, distribution smoke
• Targeted race tests for cache and inspection behavior
• git diff --check
• Regression coverage for stale plans becoming current, inspection failure preventing upgrade, fresh plugin URLs during apply, cancellation, and error replay
• Independent review, including checking targeted exit-code semantics against local Homebrew source

Login-shell smoke coverage was skipped because the host could not report UserShell. Go commands used a writable temporary cache due to sandbox restrictions.

Safety

• Status and dry-run remain read-only.
• Apply and upgrade inspect fresh state.
• No persistent cache or new configuration is introduced.
• Existing confirmation and resource-order behavior is preserved.

Documentation

• Architecture docs describe planning cache scope and targeted mutation rechecks.