fix(#551): keep __proto__/constructor tile IDs' placements, and stop a real Object.prototype leak

[BorisTyshkevich]

What & why

Closes #551. The Dashboard schema permits any non-whitespace tile ID (dashboardTileV1.id, pattern: "\\S"), so __proto__ and constructor are legal tile IDs — and JSON.parse creates __proto__ as an own property, which is how such an ID reaches the app. But every tile-keyed placement map was built with a bare items[tileId] = placement, which for '__proto__' invokes the inherited Object.prototype setter and creates no own property: the placement silently vanished and the tile fell back to the engine default size.

defineJsonField in src/core/saved-query.ts already used Object.defineProperty for exactly this input class. It is now exported as the one shared write primitive and used at every placement-map write across src/dashboard/layouts/ and src/dashboard/model/. No bare map[tileId] = … remains in those layers.

The read side was worse than the issue described

The issue stated "No prototype pollution escapes: only the local map's [[Prototype]] changes, never Object.prototype." That turned out to be wrong, and a test added during self-review caught it.

A bare read — items[tileId] where tileId === '__proto__' and the map has no own property under that name — resolves up the prototype chain to Object.prototype itself. That's a real object, so an isObject(...) guard cannot tell it apart from genuine stored data. setStylePlacement's merge-then-rewrite (current[style] = next, preserving current's other fields) therefore assigned directly onto the aliased Object.prototype, polluting Object.prototype.grid for every other placement map in the realm.

This was reproduced live and confirmed by sabotage, not reasoned about hypothetically. A paired readJsonField (own-property-only read) now guards every read of a caller-keyed JSON map that can be merged, mutated, or that distinguishes "no entry" from "an empty one".

I've corrected that claim on the issue body so the record isn't wrong.

Coverage

Round-trips tested with tile IDs __proto__ and constructor through: grafana-grid@1→@2 migration; flow@1→@2 (both report and grid presets); v2 fallback regeneration; update-placement; duplicate-tile (flow, grid@1 and the grid@2 style-map branch); and encode→decode of both the stored workspace and a portable bundle. Every assertion checks Object.hasOwn plus the exact surviving span/height and JSON.stringify round trip — not merely that nothing throws, which is the unfalsifiable shape the issue warned about.

Sabotage-verified both fixes: reverting setGridPlacement to a bare assignment turns the new test red; reverting setStylePlacement's read to the bare aliasing form reproduces literal Object.prototype.grid pollution, caught by the pre-existing deriveFlowFallback schema-validation test.

Follow-up filed

The same bug class exists at three sites outside this issue's placement-map scope (variable/dashboard ID and variable-parameter-name keyed maps in dashboard-variable-store.ts, workspace-dashboards.ts and dashboard-viewer-session.ts). Left untouched here and filed separately as inbox rather than folded into this PR.

Checklist

• npm test passes (the per-file coverage gate is non-negotiable)
• Tests added/updated in the same change as the code
• npm run build succeeds (single-file dist/sql.html)
• Layers kept honest: pure logic in src/core/, network in src/net/ (injected fetch), DOM in src/ui/
• No new runtime dependency
• README / CHANGELOG.md ([Unreleased]) updated if behavior or the deployed surface changed
• Reconciled affected tracked work (roadmap Roadmap to 1.0.0 #68, the issue body, ADR/CHANGELOG) if this change reshaped it

🤖 Generated with Claude Code

https://claude.ai/code/session_01GiubaoqEuBzAyo5C4P8Vqr