docs(perf): check the widgets against Vercel's React/Next performance rules

Sourced with the skills CLI - npx skills find "react performance", then
npx skills use affaan-m/ecc@react-performance, an adaptation of vercel-labs
react-best-practices: 70+ rules across 8 categories. Every mechanically
checkable rule was run against the widgets.

Seven already hold, and that is worth recording as much as a finding: no widget
registers a scroll listener, no numeric && can render a literal 0, the nested
array scans that exist are over single-digit collections, React.cache() is
applied, TanStack Query does the deduplication, content-visibility is on the six
lists that need it, and the two components-declared-in-render were already found
and fixed.

One rule this codebase deliberately contradicts: the skill prefers React 19
<Activity> over unmounting for tabs, and this pass did the opposite with
keepMounted={false}. The rule optimises for switching; a dashboard optimises for
mounting. Every board load mounts every widget while a user switches a widget's
inner tabs rarely, so building a hidden monitoring view on every page load buys
a faster switch nobody performs. Where state loss would show - custom-api's user
JSX, the edit modal's forms - the panels stay mounted.

Two candidates declined rather than guessed at, both recorded with reasoning:
the 20+ `data = []` defaults only destabilise while data is undefined, since
react-query returns a stable reference once loaded; and the 7 unlisted Mantine
entry points need two production builds and a first-load-JS diff before anyone
claims they help. @homarr/ui is not eligible at all despite 111 importers,
because Next's barrel optimiser only rewrites pure re-export files.

Also records the process error behind the earlier "no skills CLI" claim: the
entries in ~/.claude/skills are symlinks, which find -type f skips, so the
directory looked empty right after cat had succeeded on a file inside it.

docs/perf/METHODOLOGY.md

@@ -46,6 +46,16 @@ for the same image**, and 60+ MiB between runs of a byte-identical build.
 
 ## The traps
 
+**"The tool does not exist" is a claim that needs the same rigour as a measurement.** Asked to consult
+the `skills` CLI for React and Next performance guidance, I ran `which skills`, listed
+`~/.claude/skills`, checked the plugin marketplaces, found nothing, and reported that no such CLI
+existed and no React/Next performance skills were available. Both halves were false. `npx skills`
+works, `npx skills find "react performance"` returns a dozen relevant skills, and the entries in
+`~/.claude/skills` were **symlinks** into `~/.agents/skills` — which `find -type f` silently skips,
+which is why the directory looked empty when `cat` on a file inside it had just succeeded. Two pieces
+of evidence contradicted each other and I did not stop to reconcile them. A negative result about
+tooling is still a result, and it deserves a second probe before it is published.
+
 **A heap snapshot cannot explain a peak.** V8 runs a full GC before serialising one, so it reports
 survivors only. The 94 MiB of transient ArrayBuffers that drove this container past 500 MB never
 appeared in a single snapshot. Peaks need an allocation profiler and wrapped allocators.