MCP get_trace_flags and the web viewer share a narrower version of #3929's stale-flag defect #3999

Summary

Found while fixing #3929. The MCP get_trace_flags tool (DarlingCurrentConfigReader.TraceFlagsSql) and the
web viewer's trace-flags read (ViewerDataService.Config.cs) share a narrower version of the same defect
#3929 fixed in the TRACE_FLAGS analysis fact.

Why

Both anchor on the single newest capture:

SELECT trace_flag, status, is_global, is_session
FROM v_trace_flags
WHERE server_id = $1
AND   capture_time = (SELECT MAX(capture_time) FROM v_trace_flags WHERE server_id = $1)

This is correct for the ordinary case (one flag turns off while others stay on: the off flag's stale row has
an OLDER capture_time than the new MAX, so it is excluded correctly). It fails only in the edge case #3929's
background doc also named for the analysis fact: a capture that finds EVERY flag off writes ZERO rows (DBCC
TRACESTATUS(-1) only ever lists flags that are ON), so MAX(capture_time) cannot see that capture at all and
silently falls back to an older capture that still had a flag on - reporting a flag as currently enabled days
or weeks after it (and every other flag) was turned off.

This is narrower than #3929's fix target (that one broke on ANY single flag turning off, not just "all
flags now off"), and lives in different files (display/MCP surfaces, not the analysis fact pipeline), so it
was parked out of that PR rather than folded in.

Fix shape

Same technique #3929 used for the analysis fact: bound by the on-load-aware lookback
(AnalysisContext.LatestValueLookbackFor(CollectorScheduleDefaults.EffectiveRecurringIntervalMinutes(...)))
instead of an exact capture_time = MAX(capture_time) match, so a capture that found nothing on still
"counts" as long as it is inside the window. DarlingCurrentConfigReader.cs's GetLatestTraceFlagsAsync and
ViewerDataService.Config.cs's equivalent both need the change; check whether Lite has an analogous
viewer/grid read of the same shape.