fix(ui-core): the gallery's ResizeObserver is attached through a callback ref (#159)

[JArmandoAnaya]

Closes #159. Third of the 0.0.1-beta.2 defect fixes.

The defect

The asset gallery rendered one tile per row at every viewport width, for the life of the screen, and resizing the window did not change it. Six 160-px thumbnails occupied a single 160-px column of a 1239-px pane.

useColumns attached its ResizeObserver in an effect that began if (element === null) return. The scroller scrollRef points at is rendered inside <Async>'s children render-prop, so on mount <Async> is showing skeleton rows and ref.current is null — the effect took the early return. Both dependencies were stable (ref is a RefObject, measure a useCallback over [ref]), so it never ran again once the real element arrived. columns stayed at its initial 1.

The arithmetic was never wrong — columnsFor(1239) is 7 and always was. Only the measurement never happened, which is exactly why a suite full of assertions never saw it.

The fix

A ref object mutating is invisible to React. A callback ref is not: React calls it with the node on attach and with null on detach, so an effect keyed on that state re-runs by construction at the two moments that matter.

useVirtualizer now reads the same state value through getScrollElement, so the two halves of the screen cannot disagree about which element they are measuring. The contrast inside the file was the tell all along — rows virtualised correctly the whole time columns did not, because getScrollElement is a callback that gets re-read.

The guard, and why it cannot be a unit test

jsdom reports every element as 0×0. The virtualizer therefore renders no rows at all there, useColumns falls back to one column, and the screen's own docstring called that "correct-but-slow rather than wrong" — so gallery.test.tsx was running in precisely the state the bug produced and passing. That is this milestone's root pattern: a claim verified against itself.

So the column count is asserted in a real browser, in frontend/app/cycle/cycle.spec.ts (#59's real-server config, #48's harness — no new runner):

• the rendered count agrees with what fits, recomputed from the scroller's own measured width rather than pinned to a number the rail and the scrollbar could move;
• it is greater than one at a wide viewport — the defect's signature;
• narrowing the window to 560 px re-flows the grid, which is the half that proves the observer is attached at all;
• widening it back restores the count.

Verified by mutation, both halves independently:

mutation	result
effect back to [] deps (the original shape)	1 rendered where 3 fit — fails at toBeGreaterThan(1)
callback ref kept, observer never attached	wide case passes, re-flow fails at toBeLessThan(3)

What stays in jsdom is only what is honest there: columnsFor is exported and its arithmetic pinned (including columnsFor(0) === 1), and one test asserts globalThis.ResizeObserver is genuinely undefined before checking data-columns="1" — so the fallback path stays a stated fallback instead of quietly hiding the next regression.

Ledger

• Frontend only. No Python, no migration; openapi.json and the generated client byte-identical; FORMAT_VERSION still 12.
• No CI change — browser cycle (chromium) already runs this spec.

Checks run locally

• pnpm --filter @visionset/app cycle — 1 passed
• pnpm test — 711 annotator + 113 ui-core vitest (was 111), 22 node:test
• pnpm -r build, pnpm -r lint, pnpm -r typecheck — clean