fix(core): make MiQ#setTheme() adopt a new preset's own size

[otnc]

Summary

Closes #53. setTheme() carried the previous theme's width/height onto any object input that didn't set its own — meant to preserve an explicit setSize()/setScale() call across a later theme tweak, but it fired for any object input, including a plain { extends: 'portrait', ... } that never touched size at all. Switching to a differently-sized preset that way silently kept the old canvas's dimensions instead of the new preset's own (e.g. portrait's 630×790), with no error or warning — exactly the repro in the issue.

Fix: MiQ now tracks whether width/height were set explicitly (via setSize(), setScale(), or setTheme() itself setting one), in #explicitWidth/#explicitHeight. Only an explicitly-set dimension survives a later setTheme() that doesn't set its own size — a theme picked by name, or an object that does set width/height, is unambiguous and always wins outright. clone() carries the explicit-size state over too, so a clone behaves the same as its source for a later preset switch.

Test plan

• vitest run (full suite, 699 tests) — new coverage: adopts a differently-sized preset when nothing was set explicitly, still keeps an explicit size across a later preset switch, a named preset always wins even over an explicit size, an explicit size set via setTheme() itself survives a later plain override, and clone() carries the explicit size forward
• tsc --noEmit
• biome check
• npm run build + node scripts/check-build.js (55 module-boundary checks pass)