codegen: add a native Bun/exportable ESM target and host profile

[hyperpolymath]

Problem

The estate runtime is Bun, but AffineScript's only direct exportable ESM backend
is named and implemented as --deno-esm. The generic .js backend does not
export public functions, while --deno-esm emits exportable functions plus a
large Deno host shim.

Empty-linter can currently build a pure detector by generating an ignored ESM
intermediate with --deno-esm and immediately running bun build --target bun.
Tree-shaking removes the unused Deno host shim, and the shipped .bun.js
artefact contains no Deno references. This is a migration bridge, not a native
Bun backend.

Required capability

• Add a Bun-labelled exportable ESM target (--bun-esm or a runtime-neutral
  --esm plus explicit host profile).
• Export public functions/types consistently with the existing direct ESM
  backend.
• Provide Bun/Node-compatible filesystem, process, environment, subprocess,
  stdin/stdout, error, URL, and WASM host lowerings where used.
• Do not emit or reference Deno.* in Bun output.
• Add compiler fixtures that execute under Bun, not merely text snapshots.
• Add negative fixtures proving missing/unsupported host operations fail at
  compile time rather than silently degrading.
• Document migration from --deno-esm and whether a runtime-neutral ESM
  core can be separated from host bindings.

Acceptance probes

1. Compile a pure library and import every public export with Bun.
2. Compile a CLI using arguments, environment, filesystem, subprocess, and exit
   status; execute positive and failing paths under Bun.
3. Confirm rg -i 'deno' finds nothing in emitted Bun artefacts.
4. Demonstrate reproducible output and a non-zero compiler exit for an
   unsupported binding.

Related estate migration: remove Deno workflows, lockfiles, runtime claims, and
examples rather than merely renaming generated files.