fix: the density's brightness ceiling is the fade's steady state, and the ramp is linear

A user looked at the display and reported "the colour fading is not applied, it looks white or
full color, no opacity gradient" -- and the *numbers* were right: ink decayed, `step-time` was
1/e, `step-acquisitions` was 1 + 0.5 x 1. It was the mapping from a cell's value to a pixel.

**Neither the shader nor the blend was wrong** (the answer to the question that was asked): the
fragment write is already the weighted one (`vec4(u_color.rgb, u_color.a * ink)`) with the frame's
straight-alpha blend, and a cell at half ink over a grid line rendered 160 where the arithmetic
predicts 160. What was wrong was the **scale**:

- `full_scale` defaulted to **1.0**, so the *newest* acquisition already sat at the ceiling and
  everything above it clamped to the same pixel -- a display of one sweep and a display of five
  were one white. It is now **1/(1 - 0.5) = 2.0**, the steady state of the default per-acquisition
  fade, so one sweep reads half ink and white is reached only where acquisitions agree. A caller
  whose fade settles elsewhere states its own sum (udpscope's is `1/(1 - factor)`, in its commit).
- `gamma` defaulted to **0.45**, the value `Style::intensity_gamma` wants where the measure is a
  *dwell fraction*; on a *count* it spends most of the ramp on the last sweep (a quarter of the
  scale mapped to 0.54). It is now **1.0 -- linear in sweeps**, because half as many sweeps must
  read as half the ink.

The case that would have caught this is a **framebuffer** reading, not the grid's, and
`a_phosphor_density_is_drawn_under_the_traces` now makes it: it fades the grid to a quarter
through the time rule (`dt = tau ln 4`, asserted at 0.25 off the ink) and reads the same pixel
back, so the ramp is asserted where the eye sees it -- **`empty=21 full=83 quarter=54`** (red
channel), against the 199 / 199 the ceiling and a single sweep both read at the old defaults. A
full cell must be measurably above the background and above a quarter cell, and a quarter cell
above the background: three assertions on pixels, none of which the grid's own numbers can make.

Suite: **396 cases, 0 failed**, 4/4 ctest entries.

docs/data-and-performance.md

@@ -355,6 +355,18 @@ also why it cannot be a per-frame accumulator.
   over hundreds of columns therefore costs *columns*, plus one row of ink per column the trace
   crossed — the deposit is bounded by the screen, not by the data, which is what makes an
   accumulation affordable at the trigger's own rate.
+- **The brightness ceiling is the fade's own steady state, and the ramp is linear in sweeps.**
+  `DensityConfig::full_scale` defaults to `1/(1 - 0.5)` -- the geometric sum of the default
+  per-acquisition fade -- so one sweep reads half ink and the display reaches white only where
+  acquisitions agree, and `gamma` defaults to 1.0, because a cell's value is a count and half as
+  many sweeps must read as half the ink. Both defaults were wrong first and the *eye* found it: with
+  the ceiling at a single sweep and `gamma` at 0.45 (the value `Style::intensity_gamma` wants for a
+  *dwell fraction*) every cell one sweep touched was already full white, so a display of one sweep
+  and a display of five looked the same. The case that would have caught it is a **framebuffer**
+  reading, not the grid's numbers -- `a_phosphor_density_is_drawn_under_the_traces` now measures a
+  cell at a quarter of the scale against one at the ceiling and against the background
+  (`empty=16 full=83 quarter=54` at the current defaults, where the old ones read `199` for the
+  first two alike).
 - **The scale is applied once, on the CPU.** `DensityConfig::full_scale` and `gamma` map a cell's
   count to a luminance byte when the grid changed, and the shaders (`kDensityVS`/`kDensityFS`)
   only tint that byte. The one derivation is deliberate: a value a host reads back through