Fix mikro-orm decorator failures under bun 1.3, and pin bun in CI

[sanketsahu]

Fixes the red main. Not caused by any recent change — these failures were always there, and CI pointing at master (which never receives pushes in this fork) is what kept them invisible. The first run CI has ever had immediately found them.

The failure

3 tests, all in the mikro-orm sample:

TypeError: undefined is not an object (evaluating 'target.constructor')
  at node_modules/@mikro-orm/core/decorators/PrimaryKey.js:9:74
  at samples/mikro-orm/simple.ts:6:8

They pass locally, which is why I wrongly reported the steps as green in #9 — I verified against my bun 1.2.21, and CI's setup-bun@v1 downloads latest. I reproduced CI exactly by fetching bun 1.3.14 into a temp dir: 1249 pass / 3 fail, matching the run.

Root cause: a bun regression, reduced to 10 lines

// base.json
{ "compilerOptions": { "alwaysStrict": true } }
// tsconfig.json
{ "extends": "./base.json", "compilerOptions": { "experimentalDecorators": true } }

function legacy(target: any, prop?: string) { console.log(typeof target) }
class C { @legacy x = 1 }

bun	with extends	without extends
1.2.21	object	object
1.3.14	undefined	object

bun 1.3.x reads experimentalDecorators only from the base of an extends chain and ignores the child's value, so it applied modern TC39 decorator semantics to decorators written against the legacy protocol. Under TC39 a field decorator gets (value, context) with value undefined — hence target.constructor throwing. mikro-orm 5's decorators are legacy.

The fix, and why not the obvious alternatives

experimentalDecorators: true declared in tsconfig.deno.json, the base of the chain. Duplicated with tsconfig.json, which tsc resolves identically either way.

Things I tried and rejected, with reasons:

• Drop the extends. Works, but I checked tsc --showConfig first: that base is where strict, noImplicitAny, strictNullChecks, strictFunctionTypes and 25 other options come from. Dropping it silently disables strict mode across the codebase, which would hide real type errors. Not worth it.
• A tsconfig.json beside the sample (samples/ and samples/mikro-orm/). No effect — bun resolves tsconfig from the cwd, not from the file.
• Strip the // comments from the base config so it's strict JSON. No effect; it isn't a parse failure.

Also: bun is pinned in CI

setup-bun@v1 with no version downloads latest, which means a bun release can break CI with no change of ours — precisely what happened here. Pinned to 1.3.14, which I've verified.

Verified

Under both bun versions, since that was the gap last time:

	1.2.21	1.3.14
bun typecheck	clean	clean
bun test	1266 pass / 0 fail	1266 pass / 0 fail

Plus build:deno a no-op and the Deno port check 9/9, so nothing regressed there.