…reuse in the test

Panel PASS with ag1 notes, addressed: (1) the parenthetical taught that an inline spread passes the
rule — but  at the call site re-scatters the key even though it lints
clean. Reframed: the CALL SITE always references the constant factory (KEYS.list()/.detail(id)),
never an inline array; the spread lives INSIDE the constants file's detail(id) factory (single source
of truth). (2) The invalidation test only checked the pre-existing 'invalidateQueries' text; now it
asserts the exact constant reuse (invalidateQueries({ queryKey: CONTACT_QUERY_KEYS.all })) + the
no-inline-array / single-source guidance. Full core suite green.

…perty access) — not invented factories

Panel wrong-idiom (correct): my QUERY_KEYS shape (hierarchical all/list()/detail() factories, KEYS.list()
call, invalidate KEYS.all) CONFLICTED with what the scaffold's new:feature ALREADY generates gate-green:
  export const CONTACT_QUERY_KEYS = { list: ['contact','list'] as const };  // static tuple, accessed .list
It would have forced needless rewrites of working files + a partial-apply footgun (list becomes a function
but bare .list usages hand React Query a function as the key → broken refresh). Real scaffold features use
static tuples for fixed keys, factories ONLY for parameterized ones. build42's actual error was INLINING an
array, not the key shape. Rewrote the guidance to: USE the generated CONTACT_QUERY_KEYS.list (property, as
wired), invalidate with the SAME .list, and ADD keys in the scaffold's style — static tuple for fixed, a
factory only for a parameterized detail(id); never rewrite the static list into a function. Test now pins
the scaffold shape + property access + parameterized-only factory, and locks out BOTH earlier mis-teachings
(the inline-spread loophole and the .list() rewrite). Full core suite green.