ci: time-bound the job and the memcheck step, and retry apt fetches

[kacy]

Twice today a main run wedged with zero output inside the memcheck step — the run for #811 sat four hours, the run for #815 twenty minutes before being cancelled. Both logs show the same signature: the step header prints, then nothing at all — not one line from apt-get update, not the memcheck banner. The wedge is the step's apt preamble stalling on a mirror, before any of our code runs; the six-hour default job timeout is why it burns hours instead of minutes.

Three bounds:

• timeout-minutes: 90 on the job — no run outlives an hour and a half regardless of where it wedges.
• timeout-minutes: 30 on the memcheck step, a generous triple of its normal time (apt ~1min + the curated suite ~8min with the cases test: close the sprint's coverage gaps, and put its ownership fixes under memcheck #815 added).
• Acquire::Retries=3 plus 30-second http/https timeouts on both apt-get invocations, so a dead mirror times out and retries instead of hanging silently.

what was tested

• YAML validated with a parser locally.
• The failure evidence: both wedged runs' logs end at the step header with no apt output (run 32228468041 for fix: reuse exited mutator slots instead of growing the registry #811, run 32276137740 for test: close the sprint's coverage gaps, and put its ownership fixes under memcheck #815); the identical tree passed the identical step in 4m18s on the PR-branch run minutes earlier, and the cancel+rerun recipe cleared both — this makes the wedge fail fast and visibly instead.
• This PR's own CI run exercises the changed step end to end.