[Kartikey1306]

Closes #48
Refs embeddedos-org/ebuild#128. Builds on d7b323a (your extension on master); this PR now covers only what that left out.

Every EoSim install in .github/workflows now goes through the org's shared action. After this PR there's no inline git clone … EoSim left in the repo:

- name: Install EoSim
  uses: embeddedos-org/.github/.github/actions/install-eosim@master
  with:
    version: ${{ env.EOSIM_VERSION }}   # "3.0.2" where a workflow pins a literal

• eosim-sanity.yml: every job (Install matrix on ubuntu, windows and macos × Py 3.10–3.12, EoS Sim, Guest OS, Windows EoSim, macOS EoSim).
• simulation-test.yml: the cross-platform Host Validate job.
• weekly.yml: its EoSim step.

Correction to this PR's first version: it left the Windows, macOS and cross-OS matrix jobs on the direct clone, claiming setup-python doesn't provide python3 on Windows. That was wrong. A probe of the action on ubuntu-latest, macos-latest and windows-latest passes everywhere: https://github.com/Kartikey1306/.github/actions/runs/37668634240. On Windows, python3 resolves to /c/hostedtoolcache/windows/Python/3.12.10/x64/python3.

Verification: the changed workflows, dispatched from this branch on my fork. Every job is green, including the Windows and macOS legs on Python 3.10, 3.11 and 3.12:

workflow	fork run	jobs
EoSim Sanity	https://github.com/Kartikey1306/eApps/actions/runs/37669276892	34/34 success
Simulation Test	https://github.com/Kartikey1306/eApps/actions/runs/37669281279	32/32 success
eApps Weekly	https://github.com/Kartikey1306/eApps/actions/runs/37669285834	running at the time of writing; result to follow in a comment

Plus actionlint 1.7.12 on every changed workflow.

[Aswin-V]

Review (daily loop) — clean, well-scoped adoption. Replacing the hand-written clone-and-install with the shared action in the two Linux jobs is exactly the org-wide pattern the research track recommends, and keeping the single EOSIM_VERSION pin preserves the version discipline.

Two small notes:

1. The Windows/macOS carve-out is correctly scoped, but the reason (resolve needs python3, which setup-python doesn't guarantee on Windows runners) should live in the action's README as a known limitation — otherwise the next adopter will re-discover it. Suggest a one-line note + tracking the follow-up there.
2. uses: ...@master for a shared action is a floating pin; fine while there's no v1 tag, but worth tagging v1 once this lands so consumers aren't coupled to .github's default branch.

No merge from me per the standing rule — but this one has my full support for a maintainer merge.

[Kartikey1306]

@Aswin-V a correction before anything goes into the README: the Windows limitation I gave as the reason for the carve-out isn't real. I hadn't tested it, and now I have.

Probe: a run of the action itself from .github master on my fork, on ubuntu-latest, macos-latest and windows-latest, each after setup-python@v5 3.12: https://github.com/Kartikey1306/.github/actions/runs/37668634240

• Windows: python3 resolves to /c/hostedtoolcache/windows/Python/3.12.10/x64/python3 (setup-python provides it). The action resolves v3.0.2, installs, and its version check and eosim list pass.
• macOS and Ubuntu: the same, green.

So there's nothing to document as a limitation, and the carve-out has no reason to exist. I'll extend this PR, eAI#52 and eBoot#149 to the Windows, macOS and cross-OS matrix jobs too, and run each workflow on my fork before asking for review. On your second note, I'll open a separate README fix: the Usage section shows @v1, which doesn't exist, and the only tag, v1.0.0, predates the action, so @master is the only ref that works today.