fix: install EoSim from the pinned tag in the Windows and macOS sanity jobs

[srpatcha]

Problem

EoSim Sanity has two red jobs on every nightly run. In the most recent run
(34436907943)
20 of 22 jobs passed and exactly two failed: Windows Sanity and macOS Sanity.

Both die on their first command:

ERROR: HTTP error 404 while getting
  https://github.com/embeddedos-org/EoSim/releases/download/v1.5.0/eosim-1.5.0-py3-none-any.whl
ERROR: Could not install requirement eosim @ https://...
The term 'eosim' is not recognized as a name of a cmdlet, function, script file, or
executable program.

Root cause

.github/workflows/eosim-sanity.yml:116 and :132 install EoSim from a release
wheel asset:

pip install "eosim @ https://github.com/embeddedos-org/EoSim/releases/download/v${{ env.EOSIM_VERSION }}/eosim-${{ env.EOSIM_VERSION }}-py3-none-any.whl"

embeddedos-org/EoSim does not publish wheels. The v1.5.0 release carries one
asset, EoSim_v1.5.0_promo.mp4; v3.0.1 likewise carries only
EoSim_v3.0.1_promo.mp4. No release in the repository has ever attached a
.whl, so this URL cannot resolve for any value of EOSIM_VERSION — bumping
the version would not help.

The other three jobs in this same workflow — install-validate (9 legs across
Ubuntu, Windows and macOS), nested-simulation and nested-guest-install —
already install by cloning the tag (:38, :69, :97) and all pass, including
the three Windows legs and the three macOS legs. Only these two jobs were left
on the wheel URL.

The fix

Give windows-sanity and macos-sanity the same Install EoSim from source
step the passing jobs use, and leave their existing assertions untouched:

- name: Install EoSim from source
  run: |
    git clone --depth 1 --branch v${{ env.EOSIM_VERSION }} https://github.com/embeddedos-org/EoSim.git /tmp/EoSim
    pip install -e /tmp/EoSim

The /tmp/EoSim path is used verbatim rather than a Windows-native path because
install-validate already clones to exactly that path on windows-latest and
those legs are green.

Files changed

• .github/workflows/eosim-sanity.yml — two jobs, install step only.

Expected impact

The two failing jobs get a working EoSim, so their eosim --version,
eosim list and eosim doctor assertions actually run instead of aborting at
install. Nothing else in the workflow changes.

Risks and compatibility

Low. Workflow-only; no product code, no public interface, no dependency change.
The change makes two jobs behave like nine jobs that already pass on the same
runner images.

Two things this PR deliberately does not do, recorded so they are not
mistaken for fixed:

1. The gate can still not fail on these jobs. sanity-gate (:154) exits
   non-zero only when install-validate fails; windows-sanity,
   macos-sanity, nested-simulation and nested-guest-install results are
   printed and ignored. Run 34436907943 therefore reported
   ✅ All EoSim sanity checks passed with two jobs red. That is a separate
   defect in the same file and belongs in its own change rather than mixed into
   an install fix.
2. eosim list asserts nothing. Observed while verifying this change:
   eosim list prints Available platforms (0) and exits 0, even though
   eosim doctor reports Total platforms 149 in the same session. The steps
   named "Validate all platform configs" cannot fail on an empty list. Also out
   of scope here.

Evidence

• Scan section: .ai/autoreview/state/maint/20260910T000629/ebuild.md
  §"CI — latest run on master" (failure EoSim Sanity).
• Failing run: https://github.com/embeddedos-org/ebuild/actions/runs/34436907943
• Release assets checked with gh release view v1.5.0 --repo embeddedos-org/EoSim --json assets.

Verification

Executed in an isolated worktree branched from origin/master:

Check	Result	Duration	Command
eosim-install	pass	3s	/tmp/eosim_install_check.sh
yamllint	pass	0s	/tmp/eosimv/bin/yamllint -c .yamllint.yml .github/workflows/eosim-sanity.yml

---

Opened by the scheduled autoreview pipeline (model claude-opus-5), branched from origin/master. No human has reviewed this yet. Close it freely if the fix is wrong - a bad automated PR is a bug worth reporting.