fix(symbian): harden QuickJS and live viewport failure handling

[doodlewind]

Context

PR #176 intentionally leaves three runtime hardening questions open because arbitrary constants or Symbian-only ordering changes would be riskier than the current behavior:

• QuickJS has a stack cap but no profiled JS_SetMemoryLimit; the Qt process heap is capped separately and Rust allocation failure aborts.
• A transient viewport above the supported 640px extent reaches a permanent fail() state instead of waiting for a stable supported resize.
• Promise jobs are first drained after the first frame; defining a drain immediately after initial evaluation should be consistent across native hosts.

Acceptance criteria

• Establish measured JS, Rust, framebuffer, and Qt memory budgets on E7 and expose allocation failure as a diagnosable UI instead of an unexplained abort where feasible.
• Define and test stable versus transient viewport handling, including recovery after an unsupported intermediate size.
• Specify bootstrap Promise-job ordering across native hosts and add a shared contract test before changing it.
• Preserve deterministic __simHz timing and the validated 360x360 through 640x640 live viewport range.
• Re-run orientation and launch checks on a real E7.