chore: migrate to esbuild tooling and update Pyodide to 314.0.7 - #38

Align the build with the official Acode plugin template and fix Python
failing to load on some devices.

Tooling:
- Replace webpack/babel/postcss/sass with esbuild (dev server on :3000)
- Restore pack-zip.js at the repo root (webpack config imported a moved file)
- Copy the Pyodide runtime from npm into dist/lib on every build; dist/lib
  had been dropped from git, so clean builds shipped without Python
- Add tsconfig for acode-plugin-types, Biome dev dependency and check script
- Replace JSX with tag() calls and SCSS with plain CSS

Pyodide:
- Update to 314.0.7 (Python 3.14); run the worker as a module worker
- Bundle the Pyodide loader into worker.js so .mjs MIME types do not matter
- Fall back to ArrayBuffer wasm compilation when .wasm is not served as
  application/wasm, which otherwise hung on "loading..."
- Load packages on demand from the matching jsDelivr CDN (numpy, micropip...)
- Route stderr correctly and show clear load errors with retry on next run

Also bump to 1.2.0, add contributor, fix plugin.json main path.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

- pack-zip: resolve the root with fileURLToPath (import.meta.dirname
  needs Node 20.11+), run in-process and write via temp file + rename
- esbuild: await packing in onEnd so failures exit non-zero and rebuilds
  never pack concurrently; start from a clean dist so stale files are
  not shipped
- main: construct the worker inside try so an unsupported module worker
  shows an error and allows retry instead of leaving init stuck
- worker: only dispatch own action handlers (CodeQL dynamic method call)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Object.hasOwn needs Chrome 93+ but the build targets Chrome 90 and
esbuild does not polyfill it. On older WebViews the worker threw on the
first init message and the page stayed on "loading..." with no error.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CodeQL still flagged `actions[action](...)` as an unvalidated dynamic
method call even with the hasOwnProperty guard. Looking handlers up in a
Map means a message's action name can only reach the defined handlers,
never inherited Object methods, and avoids Object.hasOwn (Chrome 93+).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Follow CodeQL's recommended pattern for js/unvalidated-dynamic-method-call:
check the name with Map.prototype.has and verify the handler is a
function before calling it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

- Ask before running a pygame program on Acode's main page, where it can
  reach the app (Python there is not isolated like the worker); declining
  runs it in the worker without a display, with an option to not ask again
- Do not start a game that was stopped while the SDL runtime or its
  packages were still loading, including while sdl.js itself loads
- Detect real await expressions with ast instead of matching the word,
  and stop blocking loops that cannot pause (no JSPI) after a few frames
  with a clear error instead of freezing Acode
- dispose() on unmount restores window.fetch (or makes the wrapper a
  pass-through if another plugin wrapped it since) and removes the iframe

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dispose() removed the fetch route but kept the cached SDL runtime, and
the route was only installed on first load, so a re-initialised plugin
could reuse the runtime and download packages through a replaced fetch.

- install the route at the start of every run (no-op while active)
- dispose() drops the cached runtime so it is freed, not reused
- main.js clears its cached sdl.js promise and removes the script tag on
  destroy, so a later init loads a fresh module

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Removing a <script> tag does not cancel a load in flight, so after an
unmount and remount a stale sdl.js could finish last, overwrite the
shared window.acodePythonSdl, and closing the console would then stop
the wrong SDL instance.

- each load is tagged with a unique data-load-id; sdl.js registers its
  API under that id (via document.currentScript) instead of one global
- main.js keeps the API from its own current load for stop/dispose and
  ignores loads that finish after a newer one started or after destroy
- destroy bumps the run id so runs waiting for sdl.js never start

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>