32-bit GDM counters wrap silently on MT7988

[meehien]

The GDMA MIB counters are clear-on-read, so a count never read is a count
lost. The hardware raises an almost-full condition to ask for a drain, and
mtk_handle_status_irq() tests for it — but MTK_GDM1_AF/MTK_GDM2_AF are
BIT(28)/BIT(29), unconditional definitions describing a two-GDM frame
engine from the MT7621/MT7623 layout. MT7988 has three GDMs and there is no
MTK_GDM3_AF.

Measured on MT7988 with sticky per-bit accumulators on both frontend status
registers, across idle and saturated 1G and 10G: bits 28 and 29 of
MTK_FE_INT_STATUS are never set. Bits 23–25 are permanently asserted.
mtk_stats_update() is never reached from the IRQ path on this SoC.

That leaves mtk_get_stats64() and the ethtool op, which drain only when
userspace asks. With nothing asking, the 32-bit packet, error and drop
counters roll over silently — 2³² packets is under five minutes of 10G
minimum-size traffic. Byte counters are a 64-bit pair and unaffected.

The correct v3 bit assignment isn't in any public source and three
permanently-asserted bits are not evidence of almost-full, so I'm not
guessing at a new mask. This adds a delayed work that drains once a second
regardless, shaped like reset.monitor_work — three orders of magnitude
inside the wrap interval, ~40 register reads per second. The AF test stays;
it's free and will start working if the right bits are ever established.

Note for anyone testing: nothing may read /proc/mtketh/dbg_regs during a
comparison run — the two paths steal clear-on-read counts from each other.