flaky: #180 packets URL E2E 'reload shows the same list' depends on fixture age (default 15-min window)

[dborup]

Problem

The step "desktop (1400): Clear Filters on #/packets/?… closes the detail, writes #/packets, and a reload shows the same list" in test-issue-180-packets-url-modal-e2e.js fails intermittently in CI:

• master ae126374, run 37345084172: reload shows 5 packets, Clear showed 6;
• PR fix(channels): hide revoked shared channels from the channel list (#251) #257 at 02b99c45, run 37316732571: reload shows 3 packets, Clear showed 5.

Neither change touched the packets page.

Likely cause (not verified)

The step compares the row count after Clear Filters with the row count after a reload. Both use the default time window of 15 minutes. The CI fixture is freshened once and then ages while the E2E job runs. When the step runs, the newest fixture packets sit near the edge of the window, so a packet can drop out between the two renders. That makes it the same class of problem as #244, which #252 fixed for the Details test by pinning timeWindow.

Proposed fix

• Confirm the cause by reproducing it locally with an aged fixture (for example 12–15 min).
• Then make the comparison independent of the clock:
  • pin a wide timeWindow for this step, as test(packets): make the Details advert-link E2E independent of fixture age (#244) #252 did; or
  • compare the same set of packet hashes within a window that cannot move between the two renders.
• Keep what the step is meant to prove: Clear Filters writes #/packets, closes the detail, and a reload shows the same list.

Acceptance

• The cause is shown with an aged fixture (red before the fix).
• The step passes 20/20 at fixture ages of 0, 13 and 120 min.
• A mutant where Clear Filters keeps ?timeWindow= or the detail still fails the test.

[dborup]

Fixed by #280 (merged as 03f9a9d646259db99bf32fc4ffdeabde80a4d534).