Unit L: Vortex extension README, packaging scaffolding, design-doc reconciliation

[TheValiantOne]

Summary

Unit L — the documentation/packaging batch that follows Units E–J (scaffold, tool
acquisition, conflict scanning, resolve action, merge history, status dashlet). No
functional changes to vortex-extension/src/; this is README.md, a new packaging
script, and a reconciliation pass on docs/vortex-extension-design.md.

• vortex-extension/README.md — rewritten from Unit F's scaffold-era status to
  describe what actually shipped: tool acquisition, post-deploy conflict scanning +
  notification, the "Resolve Script Conflicts" action, the merge-history dashlet, and
  the dependency/status dashlet + wcc_lite acquisition. Explicit about what the two
  automatic downloads actually do and where they come from (the WSM build via a plain
  GitHub Releases GET; wcc_lite via Vortex's own authenticated Nexus-download
  mechanism with allowInstall: false, never bundled/redistributed by this project
  itself) — not just restating the design doc's proposal. Documents manual
  build/install steps and the two-tier test convention.
• Packaging scaffolding (vortex-extension/scripts/package.mjs, npm run package) — stages dist/ + info.json into a distributable zip for manual
  installation. No new npm dependencies, no CI/release workflow added (confirmed
  .github/workflows/ has no existing extension-packaging workflow to duplicate or
  extend — release.yml only builds the .NET hosts), no binaries committed.
• docs/vortex-extension-design.md reconciled against Units E–J: §3's
  CLI-first-then-MCP recommendation was superseded (MCP was Unit E's own main
  deliverable, built before any feature needed it, and no unit ever built the CLI
  path); §5 marks which UX surfaces shipped and on what shape; §2.2's setup-flow steps
  are checked against toolAcquisition.ts/bundleTools.ts; Open Questions 4 and 5
  are updated to Resolved against verified WSM-side code (AppSettings.cs's
  WSM_<KeyName> mechanism, the --version flag, release.yml).

A finding worth flagging explicitly

Reading every file under src//test/ turned up two real gaps not obvious from any
single unit's own PR description in isolation:

• No in-Vortex action triggers the initial WSM download. toolAcquisition.ts's
  acquireWsmTool is fully implemented and tested, but no unit through J wired it to
  a UI trigger — resolveAction.ts only tells the user to acquire WSM first if none
  is registered; it doesn't offer to. A fresh install today has no in-app path to get
  a WSM binary. Documented in the README's "Known gaps" section and in the design
  doc's §2.2/§5 reconciliation notes.
• No settings surface lets a user point the extension at an existing WSM install.
  The design doc originally proposed a per-game settings-panel override; it was never
  built.

Neither is a regression introduced by this PR — both are pre-existing gaps this
read-everything pass surfaced and documented, not code changes.

Open Questions 2 and 3 remain open and owner-gated

Per the root CLAUDE.md's explicit instruction and this task's own scope boundary,
this PR does not resolve, and does not imply resolution of:

• Open Question 2 (QuickBMS/wcc_lite auto-download policy) — still marked Open.
  Worth noting for the reviewer: Unit J (already merged, prior to this PR) shipped
  code that does auto-download wcc_lite via Vortex's Nexus integration, which
  answers a narrower version of this question in practice without the repo owner's
  sign-off the open question calls for. This PR does not change that behavior — it
  only documents it accurately (README's "Being transparent..." section) and flags
  the tension explicitly in the design doc rather than treating it as settled.
• Open Question 3 (public Nexus-registry listing) — still marked Open. The README
  is explicit that the extension is not yet published anywhere.

Open Question 1 left untouched

Per the task's instructions, §6 Open Question 1 (coexistence/Collections hazards) is
left exactly as it reads, word for word — a separate unit (K) is working this in
parallel in a different worktree, and this reconciliation pass doesn't add any content
elsewhere in the doc that assumes that work exists yet.

Verification

npm run typecheck && npm run build && npm run lint && npm test && npm run test:integration

All clean: typecheck/build/lint pass, 159 unit tests pass, 172 tests pass including
integration (real spawned WitcherScriptMerger.Headless process — MCP handshake,
scan_conflicts, merge_conflicts, list_merges, get_status, and the WSM_*
env-var override reaching a real process).

Two independent code-review passes on this diff both found the same real bug: the
new packaging script's posix (zip) branch nested staged files under a <name>/
subfolder while the Windows (Compress-Archive) branch produced a flat archive —
contradicting the script's own install instructions. Fixed by mirroring
release.yml's own cd <dir> && zip -r ../out.zip . pattern on both platforms (that
release.yml step runs on Ubuntu via bash zip, not PowerShell — corrected a comment
that had claimed a false parity there), plus PowerShell single-quote escaping for
paths containing an apostrophe, symmetric error handling on both platform branches,
and an explicit info.json-exists check alongside the existing dist/index.js check.

Disclosed rather than silently claimed: the posix zip branch has not been
exercised in this environment (no zip CLI available on the Windows dev machine used
for this PR) — it rests on mirroring a pattern already proven in this repo's own CI,
not independent verification. The Windows (Compress-Archive) branch was run and its
output verified flat (index.js/index.js.map/info.json at the zip root).

AI-assisted development

This PR was substantially produced by an AI coding agent (Claude Code), per
CONTRIBUTING.md's "AI-assisted development" section. Commits carry
Co-Authored-By/Claude-Session trailers.