Fix flaky //compiler/lsp-tests:lsp-tests script interrupt tests

[roger-bosman-da]

Fixes #20724

Problem

Both script interrupt tests ("scenario service interrupts outdated script runs" and "scenario service does not interrupt on non-script messages") used an interpreted foldl (+) 0 [1..10000000] to simulate a long-running script. This 10M-element fold took ~3s on a fast local machine but 25-43s on loaded CI runners (linux arm, linux intel, m1 mac), regularly exceeding the 30-60s timeouts.

The flake was observed across multiple platforms and dates:

• m1 mac: "does not interrupt" TIMEOUT at 60s (Jul 14, Aug 6)
• macOS intel: "does not interrupt" TIMEOUT at 60s (Apr 8)
• linux arm: "interrupts outdated" TIMEOUT at 30s, while "does not interrupt" barely passed at 53s (Apr 9)
• linux intel: "interrupts outdated" TIMEOUT at 30s, "does not interrupt" barely passed at 33s (Apr 23)

Fix

• Reduce fold size from 10M to 1M in both tests. On a local machine this gives ~3s total test time vs the old ~30s. The fold only needs to run long enough for the test's LSP interaction to happen during execution — 1M is more than sufficient.
• Add lower-bound timing guard ("does not interrupt" only): assert the script took at least 0.5s after the hover was sent, proving the script was still running when the hover was processed.
• Add upper-bound timing guard (both tests): fail deterministically if total test time exceeds 50% of the timeout, with a message like: "Total test time 16.2s is more than 50% of the 30s timeout — this test is at risk of flaking under further CI load. Reduce fold size or investigate why compilation/script evaluation is slow." This catches slowdowns before they manifest as flaky timeouts.
• Unify timeouts to 30s for both tests (the "does not interrupt" test previously had 60s).
• Add time to BUILD deps for Data.Time.Clock.

Test results (local)

┌─────────────────────┬────────────┬─────────┬──────────┐
│        Test         │ Total time │ Timeout │ Headroom │
├─────────────────────┼────────────┼─────────┼──────────┤
│ interrupts outdated │ 3.1s       │ 30s     │ 90%      │
├─────────────────────┼────────────┼─────────┼──────────┤
│ does not interrupt  │ 5.0s       │ 30s     │ 83%      │
└─────────────────────┴────────────┴─────────┴──────────┘

[samuel-williams-da]

Looks reasonable, is the plan to run this a few times on a PR branch before merging?
Since in its current state, its likely even more flaky than before until we tune that value better

[roger-bosman-da]

Looks reasonable, is the plan to run this a few times on a PR branch before merging? Since in its current state, its likely even more flaky than before until we tune that value better

Modified the CI to run the test 20x for each target (including M1), all test pass (CI as a whole failed tough, since the artifact failed (as it should)), results here: https://dev.azure.com/digitalasset/daml/_build/results?buildId=220514&view=logs&jobId=61ac79bb-734c-5c5d-b939-064aaa72fe3b&j=5f7337b7-8c41-55ac-da29-0870b12c9d5d

I will now revert my CI test changes & merge