dev: hide loading overlay on loadComplete() instead of init()

[The64thRealm]

The wavedash dev init gate polled window.Wavedash.initialized, which is only set by Wavedash.init(). Both prod loaders (the play embed spinner and the mainsite GameSessionFrame loader) instead key off loadComplete() / gameLoaded, which the engine default entrypoints call automatically. A Godot/Unity game that never calls init() therefore spun forever under wavedash dev while clearing fine on the site.

Gate the overlay on window.Wavedash.gameLoaded for parity with prod, and update the 10s timeout message to reference loadComplete().

I tested this and it doesn't hang with a godot project that doesn't call init.

[claude]

Claude finished @The64thRealm's task in 1m 38s —— View job

---

Code Review — dev: hide loading overlay on loadComplete() instead of init()

• Read the diff and full src/dev/dev.js
• Trace how the gate is injected and how window.Wavedash becomes available
• Check the SDK signal (gameLoaded / loadComplete()) for parity with prod
• Check CI

---

Nice, focused fix. The rationale is sound: wavedash dev should gate on the same signal the prod loaders use, so a Godot/Unity build that never calls init() doesn't hang only under dev. The message rewrite is also clearer and more actionable. ✅

The one thing worth confirming ⚠️

The whole fix hinges on window.Wavedash.gameLoaded being a public boolean property that the SDK flips when loadComplete() runs. That symbol lives in the external SDK bundle (@wvdsh/sdk-js → inject.global.js, loaded at src/dev/server.rs:29), not in this repo, so I can't verify it here.

Two small mismatches to double-check against the SDK's actual API:

• The comments and the timeout message reference the method loadComplete(), but the code reads the property gameLoaded (src/dev/dev.js:30, :48). That's fine if loadComplete() sets Wavedash.gameLoaded = true, but it's worth confirming the SDK exposes gameLoaded as a stable, documented property rather than an internal field — otherwise a future SDK rename silently reintroduces the infinite spinner.
• Confirm both prod loaders (play embed + GameSessionFrame) truly read gameLoaded and not, say, a differently-named flag. Your PR description says they do; just flagging that this repo can't prove it.

If the SDK guarantees that property, this is good to merge as-is.

Things I checked that are fine ✅

• Ordering / undefined access: the SDK bundle is a parser-blocking <script> injected before dev.js (src/dev/server.rs:589-599, src/dev/shell.html:34-35), and initGate runs no earlier than DOMContentLoaded, so window.Wavedash exists when .gameLoaded is read. This assumption is unchanged from the old .initialized code.
• Early-return path (src/dev/dev.js:30): if the game is already loaded before the gate mounts, no overlay is shown — correct.
• Polling/teardown (:47-52): setInterval clears itself and removes the overlay once gameLoaded is true. No leak.
• Behavior change is intentional: the old comment called the initialized gate "stricter than prod, deliberately"; this PR removes that stricterness on purpose to match prod. Good that the comment was updated to reflect the new intent.

Minor / optional 💡

• The old comment claimed the gate was intentionally stricter than prod. Now that parity is the explicit goal, you might add a one-line note (in the PR or a code comment) that dev intentionally mirrors prod's gate, so nobody "re-tightens" it later thinking the loosening was accidental. Non-blocking.

No blocking issues from the code itself — the only real risk is the external gameLoaded contract, which your Godot test already exercises. CI: Release ✅.
• dev-loader-hides-on-loadcomplete