Do not fail the time gate on a benchmark too small to time

[Rafael-SOWNet]

The performance gate added in #1014 failed on #1027 — a branch that changes exception message
strings and a documentation file:

 baseline  commit 6b93b401 ... Ubuntu 26.04 LTS, X64, 8 logical cores
 this run  commit d96f311f ... Ubuntu 24.04.4 LTS, X64, 4 logical cores

 method          allocated B/op   delta        mean ns/op          factor  verdict
 EvalEasy             0 →     0    0.0%     0.98 →     3.52         3.58x  SLOWER

It is not a regression. Allocation moved 0.0% there and on nearly every other row, and every
one of the seventeen benchmarks came out slower — between 1.30× and 3.58× — because the baseline
was captured on an 8-core runner and pull requests run on a 4-core one.

The inflation tracks how small the benchmark is

Which is what says it is overhead rather than code:

benchmark	baseline	factor		benchmark	baseline	factor
EvalEasy	0.98 ns	3.58×		ParseEasy	6,919 ns	1.59×
RunEasy	23 ns	1.81×		Derivate	17,215 ns	1.52×
RunHard	346 ns	1.74×		SimplifyHard	2.16e9 ns	1.30×
RunMedium	203 ns	1.57×

Fixed per-call cost — scheduling, cache state, one fewer core — is a large fraction of a
nanosecond-scale measurement and a rounding error at second scale.

The fix is the guard allocation already has

AllocationFloorBytes exists so that "a benchmark allocating almost nothing does not fail on a
percentage of almost nothing". The same argument applies to time, and time had no floor at all.
So: a baseline under 1,000 ns/op is reported and never fails on time. The constant carries the
measurement above as its justification, not an assertion.

What the gate still catches

• Allocation is untouched — still ±3% on every benchmark regardless of size, and it is the
  metric that fails. That is the point of the gate and Goal: Math OS — a ten-year vision for AngouriMath as an open mathematical reasoning platform #746 item 80.
• The time ceiling still applies above a microsecond: SimplifyHard at 2.16 s would have to reach
  6.5 s.
• Everything under the floor still prints its factor, so a real slowdown there is visible to a reader
  even though it does not fail the build.

Also worth recording

The baseline and the pull-request runners are different machine classes, which the gate prints
but does not otherwise account for. That is a separate question — re-baselining on the class actually
used would be the fuller answer — and it is not this change.

A gate that goes red without a defect is a gate people learn to ignore, and this one is a day old.