mngr_lima: report limactl runtime failures as provider-unavailable instead of leaking ProcessError

[gnguralnick]

Problem

When limactl is installed and correctly versioned but an invocation fails at runtime (e.g. it crashes at startup), Lima discovery surfaced an opaque, unclassified error and left the workspace stuck offline. This is what a real user hit: on their Mac, limactl list --json panicked at package init (panic: user: unknown userid 501 — a transient macOS Directory Services / getpwuid fault), so every Lima discovery poll failed and their local workspace was unreachable with no actionable reason.

Root cause, in mngr_lima:

• The limactl_* wrapper helpers called cg.run_process_to_completion(...) with the default is_checked_after=True, which raises a raw ProcessError on a non-zero exit — making the if result.returncode != 0: raise LimaCommandError(...) line below each call dead code.
• ProcessError (a ConcurrencyGroupError) is neither LimaCommandError, OSError, nor ProviderUnavailableError, so it slipped past discover_hosts's handlers and the intended graceful degradation, bubbling up as a generic discovery error.
• Separately, mngr only modeled Lima as "unavailable" for a missing (LimaNotInstalledError) or too-old (LimaVersionError) limactl — a binary that is present but crashes at runtime was unmodeled.

Fix

1. Correctness: the limactl_* helpers (list, stop, delete, disk create, disk delete, show-ssh, shell, and get_lima_version) now pass is_checked_after=False, so a non-zero exit raises the intended domain LimaCommandError instead of a raw ProcessError. Side benefits: limactl_disk_delete's tolerate-absent-disk path and limactl_shell's documented non-zero return (inspected by its sole caller _wait_for_cloud_init) work as intended again.

2. Semantics: new LimaCommandUnavailableError(ProviderUnavailableError). In discover_hosts, a present-but-crashing limactl's LimaCommandError/OSError is converted to that error and propagated, so the provider is reported unavailable (Provider 'lima' is not available: ...) with the standard retry/backoff — matching how other providers report an unreachable backend — instead of the old opaque error. A genuinely absent or too-old limactl still degrades gracefully to a local all-offline host view.

Tests

• limactl_test.py: limactl_list raises LimaCommandError (not ProcessError) against a crashing fake limactl — the regression guard for the is_checked_after=False fix.
• instance_test.py: discover_hosts raises LimaCommandUnavailableError/ProviderUnavailableError when a present, correctly-versioned limactl crashes on list; and still degrades to [] for a too-old limactl. Both use a shared install_fake_limactl helper (in testing.py) that writes a fake limactl and prepends its dir to PATH.
• mngr_lima package: 134 passed, 0 failed (just test-quick); uv run ty check clean; ratchets clean. The full monorepo suite runs in CI.

Notes

• Two commits: the fix, then a DRY consolidation of the fake-limactl test helper into testing.py (from the autofix gate).
• This is the mngr_lima half. The complementary minds-side improvement — detect the limactl panic signature, retry discovery a few times before flipping to host_offline, and show an actionable message instead of a bare "offline" — is a separate follow-up, and upstream Lima's fail-hard Must(user.Current()) package init is the deeper cause.

[joshalbrecht]

this seems weird and bad -- why not:

try:
    result = cg.run_process_to_completion(cmd, timeout=timeout, is_checked_after=False)
except SomeTypeOfError as e:
    raise LimaCommandError("stop", e.returncode, e.stderr, e.stdout) from e

Then all of the information gets preserved? And we then no longer can forget to check the exit code

It's weird to be disabling the check, then checking it?

[joshalbrecht]

we don't check this one... what callers exist?

can they properly handle this raising for a non-zero exit?

it'd be nice to make it all consistent so that we cannot have silent failures

[joshalbrecht]

the overall work here seems good, I just have the above stylistic complaints

[joshalbrecht]

lgtm after they are addressed