feat(gamebridge): launch an instance with devbridge switched on

[Flatts3000]

What this changes

Adds gamebridge launch, which starts a CurseForge instance with devbridge switched on and a world
loaded. Closes #5.

gamebridge launch --instance "C:/.../Instances/Trashlands" --port 8604 --world "New World" \
                  --width 1280 --height 720 --wait

Route 1, and why it was cheaper than the issue estimated

The issue priced route 1 as "reimplements a launcher... realistically several PRs". That estimate
assumed resolving and downloading libraries. It turns out the CurseForge app already keeps a
vanilla-shaped install beside its instances - versions/, libraries/, assets/, natives/
and bundled JREs under Install/. So this parses manifests in a documented format and downloads
nothing.

It also only ever reads minecraftinstance.json. The issue warned that writing that file is a
known way to break an instance; that risk does not apply to a reader, which removes the main
objection to this route.

The work is: merge the loader manifest with what it inheritsFrom, apply library and argument
rules, build the classpath, substitute ${placeholders}, pick the JRE the manifest asks for, and
exec java with -Ddevbridge.port and --quickPlaySingleplayer.

Two bugs worth keeping in the record

Present-but-null is not the same as absent. The NeoForge manifest carries "assetIndex": null
and "jar": null, so get(key, default) returns the null instead of falling through to vanilla's
real value. Caught by a dry run; would have started a game with no assets.

Rule-gated arguments come from the manifest and nowhere else. Vanilla defines
--quickPlaySingleplayer, --width/--height and --quickPlayPath as feature-gated entries with
placeholders. Appending them by hand as well passed the flag twice, and jopt-simple rejects a
repeated single-value option with Found multiple arguments for option, which reads like a
malformed world name rather than a duplicated flag. Only found by actually launching - the dry
run looked fine to me until I diffed the flag counts.

Verified, end to end, against a real instance

This is the first thing in this repo proven against a running game rather than by inspection.

• --dry-run produces a command whose 102 classpath entries all exist on disk (0 missing), with
  the bundled java-runtime-epsilon JRE and net.neoforged.fml.startup.Client.
• A real launch booted the Trashlands pack, quick-played into "New World" as offline player Dev,
  and devbridge answered on [::1]:8604. netstat -p TCPv6 confirmed the listener's PID was the
  process this launched, not something already running - the wrong-game hazard the issue describes.
• --wait reported up: integrated, protocol 1, so the version handshake works against a freshly
  built jar.
• Full sequence through the launched game: cmd as @s returned
  Set minecraft:overworld to time marker minecraft:day; input, pause and hud all replied;
  screenshot wrote a valid PNG at exactly 1280x720, proving the resolution arguments took
  effect; stop closed it cleanly.
• The stale jar already in the instance has no protocol field, and the client's version guard
  fired on it with both numbers named. That is the drift check from feat: bring gamebridge into this repo, and version the protocol #4 working on a real mismatch.

That run also retroactively verifies #3, which merged unverified: the ping reply showed
"pauseOnLostFocus": false and "inputLocked": true from a live client.

Note

The instance's mods/devbridge-26.1.2-0.1.0.jar was refreshed from build/libs during testing,
since the copy there predated the protocol field. That is ordinary after a rebuild, but worth
flagging as a change made outside this repo.