test_html_rebuild_mo can fail after a slow build

Describe the bug

Hej, while investigating the CI failures on #14677, I noticed that tests/test_intl/test_intl.py::test_html_rebuild_mo can fail even when Sphinx's outdated-file check is correct. The Docutils HEAD and LaTeX jobs reported updated == set() where the test expected {'bom'}.

The test moves bom.mo five seconds forward from its previous mtime. If the bom document was read more than five seconds after that mtime, the resulting .mo mtime is still older than the document's recorded read time. Sphinx then correctly considers bom up to date.

This to me is a test timing problem.

How to Reproduce

To force the timing condition in the original test, insert this line immediately after _, bom_file = _get_bom_intl_path(app.srcdir) in test_html_rebuild_mo:

 _set_mtime_ns(bom_file, app.env.all_docs['bom'] * 1_000 - 10_000_000_000)

Then run:

uv sync
uv run pytest -q --tb=short tests/test_intl/test_intl.py::test_html_rebuild_mo

The original test advances that ten-second-old catalog mtime by only five seconds, so its final assert updated == {'bom'} fails with updated == set(). This is a bit rough, but illustrates the problem.

Environment Information

Platform:              linux; (Linux-7.0.0-31-generic-x86_64-with-glibc2.43)
Python version:        3.13.13 (main, Apr  7 2026, 20:49:46) [Clang 22.1.1 ])
Python implementation: CPython
Sphinx version:        9.1.0
Docutils version:      0.22.4
Jinja2 version:        3.1.6
Pygments version:      2.21.0


The forced test run used the source checkout above with Docutils 0.22.3 and Pygments 2.19.2.

Sphinx extensions

[]

Additional context

The AI under #14674 already proposes a different change to this same test, alongside unrelated test changes, but the fix doesnt seem to fully address the timing problem to me, as it is not fully uncoupled. It fixes the observed slow-build case but still chooses the timestamp from the wall clock.