Measure the claim, not the workflow around it

[tonytonycoder11]

Fixes main, which I turned red in #163.

What actually went wrong

A run measured 290 ms against a usual 30 and failed the 75 ms ceiling I added yesterday. My first read
was that the ceiling was too tight. It was not: the measurement was measuring the wrong thing, and I had
put an assertion on it without reading what it covered.

The clock started here and stopped after the search:

val started = TimeSource.Monotonic.markNow()
...
if (qdrant.collectionExists(collection)) qdrant.deleteCollection(collection)
qdrant.createCollection(collection) { ... }
qdrant.upsert(collection, wait = true) { ... }   // blocks until the write is durable
val hits = qdrant.search(collection) { ... }
val elapsed = started.elapsedNow()

Five round trips, one of them a durable write. That number moves with the server's disk and its
optimiser, and the README was quoting it as how long a cold process takes to answer its first search. On
a loaded shared runner it can be 290 ms with nothing here being slower.

What it measures now

Process start, client construction, connecting, one search. The collection is seeded by the job with
curl before the binary runs, because a collection the process created itself would be inside its own
measurement.

The write path still runs, past the clock, on a separate collection. Those calls reach reflection the
read path does not, and an image proven only to read is not proven, so losing that coverage to tighten a
number would have been a bad trade.

The ceiling

150 rather than 75, and the comment says it is provisional. I set 75 from four samples that turned out to
be four samples of a narrower thing than I was measuring. It should be tightened once there are enough
runs of the new span to know its shape, rather than from another handful.

The README

The comparison row no longer carries a frozen figure. It says a cold process answers in tens of
milliseconds, measured and bounded on every push, which stays true after a fast runner or a slow one
without anyone editing it. The paragraph under the table says what the timed span covers, since that is
the part that made the old number misleading rather than merely stale.

[trueup-by-nacode-studios]

This pull request adds no capability. The code it touches can already read the environment (2 places).

What I could not follow

1 call resolve to a name whose type is written nowhere, so what they reach is not established here. Across everything it read that is 1 of 51, 2%.

• System.getenv("QDRANT_PORT")?.toIntOrNull() — example-native-image/src/main/kotlin/dev/kdrant/example/nativeimage/Smoke.kt:35

If one of those reaches the network or starts a process, this report does not show it.

_{3 files read · 2324 ms · against b5112d0 · engine 1.4.1}