bun-compat: add an opt-in Bun platform mode with a real globalThis.Bun namespace

[proggeramlug]

Problem

Perry's existing Bun shim pack (#6560, #8514) intentionally recognizes a few direct syntax forms while leaving bare Bun unresolved and typeof Bun === "undefined". That is correct for Node-targeted bundles, but it prevents compiling applications whose source graph was built for the Bun platform.

This issue is self-contained and must preserve the current Node-compatible default.

Repro

console.log(typeof Bun);
console.log(Bun === globalThis.Bun);
console.log(typeof Bun.hash);

const { stringWidth } = Bun;
console.log(stringWidth("abc"));

const key = "file";
console.log(typeof Bun[key]);

Bun 1.3.14 prints:

object
true
function
3
function

Current Perry deliberately prints undefined for the first line and does not provide an object that supports equality, destructuring, computed access, nested namespaces, or feature detection. Only selected direct member expressions are lowered syntactically.

Proposal

Add an explicit Bun-target compilation mode (CLI/config spelling open for design, e.g. --platform bun). In that mode:

• globalThis.Bun is a stable runtime namespace object;
• bare Bun resolves to that same object;
• typeof Bun is "object";
• direct calls, method extraction, destructuring, optional chaining, and computed property access share one registry;
• the namespace exposes version and isStandaloneExecutable with documented Perry semantics;
• unsupported members are absent or throw a precise compatibility error according to Bun-observable behavior.

The default mode must retain today's typeof Bun === "undefined" behavior so Node-targeted feature detection does not regress.

Individual API implementations can land independently as exports of the existing native "bun" module; this issue only owns the opt-in global namespace and registry wiring.

Motivation

A Bun-native CLI graph contains guards such as if (typeof Bun === "undefined") throw ... and nested calls such as Bun.YAML.parse. Perry's current direct-call shim cannot enter those paths even when the underlying capability already exists.

Verified on Perry 0.5.1520 (898e531590d874923314e48cf11950fc47c7f098).