Crate: configurable animation model + desktop picker

[CaYatur]

What

Closes #16, closes #17. The crate opening animation becomes a real, selectable setting.

shared/crate.ts defines five variants with their durations:

Variant		Duration
reel	classic sideways strip that slows onto the reward	~4 s
spin	vertical slot-machine column	~3.2 s
flip	face-down cards flip until the reward shows	~2.8 s
burst	short shuffle, then the reward pops in	~1.6 s
instant	no animation, immediate reveal	0

The desktop picker lives in the Store tab with a plain-language description of each, including how long it takes.

Decisions

reel is first and is the default. It is exactly what every existing store plays today, so an operator who never opens this setting sees no behaviour change at all.

Per-server, not a global app preference. The people who see this animation are the players buying from that server's web panel — not the operator sitting at the desktop app. It therefore lives in that server's store config, and is carried on StorePublic as well, because the panel plays it from the buyer-facing payload rather than the admin one.

normalizeCrateAnimation never throws. An old config, a hand-edited store.json, or a renderer sending nonsense all coerce to the default. A bad animation string must never be able to stop a player receiving something they already paid for — the purchase has already been deducted by the time the animation matters.

instant exists on purpose. A 4-second animation on every purchase is a real annoyance on a busy store and on slow devices, and there was previously no way to turn it off.

Verification

• typecheck + build clean; MSMS_SMOKE_WEB exit 0; MSMS_SMOKE exit 0.
• New smoke units: a valid id round-trips; seven bad inputs (undefined, null, '', 'nope', 42, {}, []) all fall back to the default; instant has zero wait; an unknown id times like the default; the default is the first picker option; a fresh store defaults correctly; set → getStoreConfig → publicStore all carry it; and setCrateAnimation('not-real') is coerced, not stored.
• en/tr store block parity: 64/64.

Disclosed gaps

• Nothing renders these variants yet — this slice is the model, the persistence and the picker. The panel still plays the existing reel regardless of the selection; Crate: multiple animation variants in the panel reel #18 is the next PR. Choosing flip today stores flip and changes nothing visible.
• The desktop picker was not rendered in a browser; the smoke covers the pure coercion and the store round-trip, plus that the app mounts.
• Migration of an old store.json (no crateAnimation key) is handled by normalising on read, verified by construction rather than against a real pre-existing file.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[CaYatur]

/code-review — self review

One real finding, fixed on-branch.

The picker could claim a setting the server never accepted

setCrateAnim(animation)
await window.msms.setCrateAnimation(id, animation)
toast('success', 'store.saved')

Two problems in three lines:

• No catch. Every other mutation in this view (changeBalance, saveProduct) wraps the IPC and toasts the error. This one did not, so a failure rejected into a void-ed promise — no error toast, no revert, and the select still showing the new value. The operator walks away believing crates now play flip.
• It trusted the request, not the response. setCrateAnimation deliberately coerces an unrecognised value to the default rather than storing it. Since the UI never read the return value, a coerced save would have left the picker displaying something different from what is actually stored — the exact divergence the coercion exists to prevent.

Now it captures the previous value, reverts on failure with an error toast, and adopts the animation the main side returns.

Checked and fine

• The picker saves on change with no Save button, unlike the currency field next to it. Deliberate: a select that applies immediately is the conventional affordance, and the toast confirms it.
• normalizeCrateAnimation runs on read in getStore, so a legacy store.json is normalised in memory even before anything writes.
• StorePublic carries the animation, so the buyer's panel gets it without needing store-scope access to the admin config.
• Adding a required field to StorePublic/StoreConfig did not break any other construction site — typecheck is clean.

Accepted, not fixed

The smoke leaves a synthetic crate-smoke-server in dev-root's store.json; there is no delete-store API and I would rather disclose that than invent one for a test.

Re-verified: typecheck + build clean, MSMS_SMOKE exit 0.