Jaguar1 enables EDCCA at bring-up where the vendor driver ships it off

[snokvist]

RtlJaguarDevice::apply_cca programs the BB EDCCA thresholds at 0x8a4 from
the live IGI whenever the EDCCA gate is enabled — which is the default — and
0x8a4 is otherwise parked by the BB init table at 0x7f7f, the
never-trigger value. So on Jaguar1 the enable is the active step: bring-up
takes a chip whose BB would never raise EDCCA and gives it a real operating
point.

That is a policy choice worth stating explicitly, because the Realtek vendor
driver makes the opposite one:

• CONFIG_RTW_ADAPTIVITY_EN 0 — adaptivity (EDCCA) off by default.
• rtw_adaptivity_en, rtw_adaptivity_mode, rtw_adaptivity_th_l2h_ini and
  rtw_adaptivity_th_edcca_hl_diff are all module parameters, mode 0644.

devourer enables it and hard-codes both th_l2h_ini (−17, −14 on 8814A) and
the H2L offset (−7).

What this costs, measured on an RTL8812AU injecting 300 frames at 6M on an
idle channel, with two independent witnesses of different families decoding
(RTL8822C and RTL8733BU, agreeing per arm within ~2%):

arm	delivered
both gates on (the default)	5.7% / 15.7%
EDCCA off only	95.3% / 95.7%
primary CCA off only	31.0% / 12.7%
both gates off	94.0% / 95.0%

The default costs this family ~90% of what it is asked to transmit, and it is
EDCCA that does it — tests/dis_cca_tx_onair.sh reaches the opposite
conclusion on Jaguar3, where the 8812AU is only ever the flooder.

This is not an argument for dis_cca. With EDCCA off and primary CCA left on,
the same injector delivers 95% on an idle channel and still 78% under a
co-channel flooder — it defers when it should. With both gates off it collapses
to 0.3%, because it stops waiting for a gap and collides instead. The gate
worth turning off is the one the vendor never turned on.

Three things that might follow, in increasing order of change:

1. Expose th_l2h_ini and the H2L offset as tuning config, matching the
   vendor's module parameters. Smallest change; makes the operating point a
   decision rather than a constant.
2. Make the Jaguar1 EDCCA enable itself configurable, defaulting to the
   current behaviour so nothing moves unless asked.
3. Follow the vendor and default it off on Jaguar1, on the grounds that the
   parked 0x7f7f is what the BB table ships and what every other driver
   leaves in place.

Raising rather than proposing: a default change has a blast radius I cannot
measure from one bench, and 5 GHz regulatory adaptivity requirements are a
real reason a project might want it on even at this cost. Filed out of
#427, which only split the gate so the two could be told apart.

Verified on RTL8812AU (Jaguar1) and RTL8822C (Jaguar3). Not re-run on
8822EU/8812EU — I do not have those parts.