fix(deps): name the platform a package-manager command belongs to

[filip131311]

Fixes #641.

Reproduced on a real Linux VM (Ubuntu aarch64, published 0.18.0, no adb):

$ argent run boot-device --avdName Pixel_9
Android SDK Platform Tools not found. Install with `brew install --cask android-platform-tools` …

What changed, and why not the obvious thing

My first instinct — and the issue's second suggestion — was to delete the package-manager specifics
entirely. Two things killed that:

• sdkmanager ships inside the SDK command-line tools. A reader with no SDK cannot run it, so
  it can't be the headline replacement. It's kept, but qualified with "if you already have the SDK
  command-line tools".
• Removing brew would have been a real regression for macOS. adb gates every USB-phone and
  already-running-emulator path (launch-app, keyboard, settings-permissions, tv-remote,
  reinstall-app, open-url on Android) — none of which need the emulator. For those,
  brew install --cask android-platform-tools genuinely is a complete one-command fix. Dropping it
  would have traded Linux's wrong advice for macOS's missing advice.

So the rule is labelled examples, no host branching: every hint leads with a route that works
anywhere (SDK Manager, standalone download), and any package-manager command names its platform.
No process.platform read, no mechanism, nothing new to test per host — and Windows is fixed too,
which a darwin/non-darwin split would have missed.

Also in scope

• ffmpeg (capture.ts) had the identical defect and is the more reachable one on Linux, where
  ffmpeg is the encoder for Android recording. Same treatment. It additionally warns that the build
  needs libx264: capture.ts hardcodes -c:v libx264 with no fallback, and Fedora's default
  ffmpeg-free package omits it — so that install "succeeds" and then dies with an exit code and no
  mention of a codec.
• xcrun now leads with the disqualifier. classifyDevice is purely shape-based, so any
  8-4-4-4-12 udid routes to the iOS branch on any host; a Linux reader was being told to run
  xcode-select --install before being told iOS needs a macOS host. (Making every iOS tool fail
  up front on a non-macOS host is the real fix for that class — it's a behaviour change with its own
  failure code, so I left it out; happy to file it.)
• One SDK root added. Following the sdkmanager route left the tool still failing: the
  Homebrew command-line-tools cask roots the SDK at /opt/homebrew/share/android-commandlinetools,
  which wasn't probed. A remediation string that doesn't unblock isn't fixed.
• skills/argent-screen-recording/SKILL.md quoted the old brew install ffmpeg — updated so the
  shipped skill and the runtime error agree.

Not touched: watermark.ts's /opt/homebrew/bin/ffmpeg and the existing Android roots. Those are
search paths — probing a Homebrew prefix on a machine without Homebrew simply misses.

Verification

On the Linux VM: the exact repro now returns the labelled hint. Then, satisfying it, the dep gate
advances to the next dependency (emulator) instead of repeating — i.e. following the hint
actually unblocks adb, which is the only thing that makes a remediation string correct.

One honest caveat from that exercise: Google's standalone Linux platform-tools zip is x86-64 only,
so on this aarch64 VM the downloaded binary can't execute. That's a limitation of the upstream
download, not of this change, and the SDK-Manager route is unaffected — but it means the
"download-and-run" leg was verified by resolution, not by executing Google's binary.

Tests: all existing assertions pass unchanged — keeping the labelled brew cask means the
/android-platform-tools/ assertions in check-deps.test.ts and http-dep-gate.test.ts never needed
relaxing. Added a guard that states the actual invariant rather than banning one word: every hint that
names brew/apt/dnf/pacman must also name the matching platform, every Android hint must offer
a platform-agnostic route and $ANDROID_HOME, and the xcrun hint must mention the macOS-host
requirement before xcode-select. Banning the string brew would have passed apt install adb —
the same bug — while failing the correct fix.

tool-server 3092 passed.

🤖 Generated with Claude Code