REQ-DEM-010: GMSK is demodulated at BT 0.3 only, and the row asks for a BT parameter

[TGoodhew]

Found while implementing #125. REQ-DEM-010's catalogue row reads "GMSK | with BT parameter".
This build demodulates GMSK, and its BT is fixed at 0.3.

Why

GMSK is demodulated through its linear representation: π/2-BPSK shaped by the principal Laurent
pulse c₀(t). The catalogue has exactly one such pulse — PulseFilterType.Edge, the c₀(t) of
3GPP TS 45.004, which is the pulse for BT = 0.3, GSM's. Round-tripped through the simulator it
gives 0.002179 %rms with every symbol recovered, so GMSK at the BT that matters most is measured
properly; a signal filtered at any other BT is measured against the wrong pulse.

What a BT parameter would take

c₀ is derivable for any BT rather than tabulated, so this is a bounded piece of work:

1. Frequency pulse g(t) = a rectangle of one symbol convolved with a Gaussian of the wanted BT.
2. Phase pulse q(t) = ∫g, normalised to a half at infinity.
3. c₀(t) = Π s(t + iT) over the pulse's span, with s(t) = sin(2πh·q(t)) for the first half and
   sin(πh − 2πh·q(t − LT)) for the second, at h = 1/2.

At BT → ∞ the construction collapses to half a cosine across two symbols, which is
PulseFilterType.Msk — so one function would produce MSK's pulse, GSM's c₀, and every BT between
them, and the two hand-written entries become special cases of it. That is the shape the answer
wants to take.

Also worth deciding at the same time

Whether the Gaussian entry already in the catalogue is what a user will reach for when they mean
this. It is the premodulation filter — what goes in front of the frequency modulator — not the
linear pulse a demodulator matches against, and measured here, using it as a transmit pulse gives a
signal that reads 11.1 %rms against the constellation it is supposed to carry. The names are close
enough to confuse, and REQ-DEM-021 already found it necessary to say in a box of its own that EDGE
is not a Gaussian.

[TGoodhew]

Measured against a real GMSK transmitter, 31 August 2026

The E4438C has no GMSK format: GMSK is its MSK through the GAUSSIAN pre-modulation filter at
BbT 0.3, which is what --demod-check now transmits. Demodulated against c₀(t) with the
equaliser on:

5.76 %rms EVM, and 511 of 511 bits of the PN9 recovered.

The bits are perfect and the error vector is not, which puts a number on the limitation this issue
is about — and shows it is a floor of the model rather than a fault: c₀ is the principal
component of GMSK's Laurent decomposition and not the whole of it, so a linear receiver leaves the
higher components as error. Consistent with the ~0.3 % of energy those components carry at BT 0.3.

Two consequences worth recording here:

• The chain's own round trip cannot see this. It reads 0.002 %rms because its generator
  transmits c₀ as a linear pulse — the same approximation at both ends, which measures the
  arithmetic and cannot measure the approximation. That is now written on the test.
• 5.76 %rms is the number to compare a suspect GMSK signal against, not zero. It is in the help.

Deriving c₀(BT) as this issue proposes would make BT a real parameter; it would not remove
this floor, which needs the higher Laurent terms as well. Worth separating those two when the work is
scheduled.