Clarify the published performance results

docs/performance.md

@@ -5,10 +5,11 @@ published baseline: one host, one session, with every limitation stated. The mea
 
 ## How the numbers are produced
 
-The driver lives at `Tests/Editor/PerfBaseline.cs`. It stages deterministic `PlayModeDataObject` fixture datasets (100 and 1,000 assets in this baseline), then measures inside the
-editor with monotonic `Stopwatch` timers, so no tool transport ever pollutes a sample:
+The driver lives at `Tests/Editor/PerfBaseline.cs`. It stages deterministic `PlayModeDataObject` fixture datasets, then measures inside the editor with monotonic `Stopwatch`
+timers, so no tool transport ever pollutes a sample. The current driver runs 100, 1,000, and 10,000 assets; this published baseline contains only the 100- and 1,000-asset results:
 
-- **Fixture import** is the wall time of the single `AssetDatabase.Refresh` that imports the staged files.
+- **Fixture import** is the wall time of the single `AssetDatabase.Refresh` after fixture creation. The timer excludes the preceding `AssetDatabase.CreateAsset` loop, so this
+  number does not measure the total cost of creating or importing the dataset.
 - **Window open to index ready** runs from `CreateGUI` until the production search cache reports populated — the same flag the window's asynchronous batch loader flips for a user.
   _Cold_ is the first open after staging; _warm_ numbers come from repeated open-close cycles of the same already-imported dataset, after two discarded warm-ups.
 - **Search first results** types a query into the production search field and measures until the results list carries a row, including any deferral the search performs. The results
@@ -46,16 +47,18 @@ Reading the numbers:
 
 - The **cold** open includes one-time session costs (type catalog construction, first asset resolution), so it is not the number a daily user sees after the first open; the warm
   median is the steady-state open cost. The cold single samples also vary with session history, which is why they are recorded as single samples and not medians.
-- **Search first results** stays well under the acceptance target of 100 ms including debounce at both sizes; the visible result cap keeps row building bounded.
+- **Search first results** has medians below 100 ms at both sizes, including any search deferral. The maxima exceed 100 ms (235.1 ms at 100 assets and 107.0 ms at 1,000), so these
+  five-sample runs do not establish a worst-case or p95 guarantee. The visible result cap limits row building to 25 results.
 - The **warm** open grows roughly with dataset size at this scale, and the async batch loader keeps the window responsive while it fills; see
   [The object list fills in gradually](troubleshooting.md#the-object-list-fills-in-gradually) for what that looks like in practice.
 
 ## Current gaps
 
 Recorded explicitly rather than smoothed over:
 
-- A 10,000-asset dataset is not yet published: the driver stages and measures it, but a clean run has not been recorded on this host yet, because the package's asset postprocessor
-  currently loads every imported asset synchronously during a large import burst, which dominates that scenario and is tracked in the repository issue tracker (#226).
+- A 10,000-asset result is not yet published. An earlier attempt exposed synchronous per-asset loads in the asset postprocessor
+  ([#226](https://github.com/wallstop/DataVisualizer/issues/226)). The type-only relevance fix has merged in [#228](https://github.com/wallstop/DataVisualizer/pull/228), but a
+  post-fix 10,000-asset run and the Unity test suites still need a host editor session. The table above is the earlier baseline; it does not demonstrate the fix's performance.
 - Play Mode entry overhead and compile timings are separate roadmap areas (T03, T08) and are not measured here yet.
 - Cold scenarios are single samples; the full acceptance wants 30+ repetitions per warm scenario and cross-host spread (T01, T12).