Avoid the deprecated generic timedelta unit in test_subsecond_outputdt

[sujeito-operator]

Description

Contributes to #2682. Not marked as closing it — see the last paragraph.

I ran pytest tests/ on main to see how much of the list in #2682 is still there.
On numpy 2.5.2 / Python 3.12.3 it emits exactly 2 warnings, and both are the
same DeprecationWarning raised from the same line of tests/test_particlefile.py.
Every FutureWarning in the list pasted in the issue is already gone.

The one that is left:

tests/test_particlefile.py::test_subsecond_outputdt[100]
tests/test_particlefile.py::test_subsecond_outputdt[200]
  numpy/_core/numeric.py:2443: DeprecationWarning: The 'generic' unit for NumPy timedelta
  is deprecated, and will raise an error in the future. This includes implicit conversion
  of bare integers (e.g. `+ 1`).Please use a specific unit instead.
    result = (less_equal(abs(x - y), atol + rtol * abs(y))

elapsed_t and expected_t are timedelta64[ms] arrays, and assert_allclose
evaluates atol + rtol * abs(y) internally — so the bare integer atol=1 is added to a
timedelta64, which is the deprecated 'generic' unit. numpy says it "will raise an error
in the future", so this one is a test scheduled to break rather than noise.

This compares the millisecond counts as int64, which keeps the 1-millisecond tolerance
exactly as it is rather than reinterpreting it.

What I ran

• pytest tests/ on main at c603cc3, unpatched:
  5 failed, 622 passed, 95 skipped, 10 xfailed, 2 warnings in 440.45s.
• The same command with this change:
  4 failed, 623 passed, 95 skipped, 10 xfailed in 468.54s — 0 warnings, no
  warnings summary section is printed at all.
• Controlled both ways with -W error::DeprecationWarning: test_subsecond_outputdt
  fails on both parametrisations without this change and passes with it.
• pytest tests/test_particlefile.py — 43 passed, 6 skipped, 2 xfailed.
• ruff format --check and ruff check clean.

The suite has 4 pre-existing failures on main in my environment, none of them
changed by this PR. The 5 → 4 above is not one of them being fixed: it is
tests/sgrid/test_accessor.py::test_assert_metadata_ds_consistency_dropped_dim, which
failed in the first run and passed in the second with a hypothesis FailedHealthCheck —
"input generation is slow: Hypothesis only generated 9 valid inputs after 1.00 seconds" —
a statement about how fast this box is, not about the test. test_fieldset_describe_backends
is an ImportError for an optional backend I do not have installed.

The other three are not unrelated, and that is the one thing here I would not want you
to miss. The three test_maybe_convert_python_timedelta_to_numpy cases fail on the same
numpy deprecation as the warning above — but reached from your own source, not from a test:

    if dts:
>       return sum(dts)
E       DeprecationWarning: The 'generic' unit for NumPy timedelta is deprecated, and will
        raise an error in the future. ...
src/parcels/_core/utils/time.py:185: DeprecationWarning

sum() starts from the integer 0, so 0 + timedelta64 is the same deprecated
conversion. Because it is raised inside parcels.*, the "error:::parcels.*" rule you
already have turns it into an error, the except Exception around it catches that, and
the user gets ValueError: Could not convert datetime.timedelta(days=5) to np.timedelta64.
CI on main is green today because it has not resolved to numpy 2.5.2 yet; numpy >=2.1.0
has no upper bound, so it will. That one is a change to src/, not to a test, so it is
not in this PR.

Deliberately not included

#2682 says that once the list is empty you can implement #2413 and fail on warnings.
#2413 is already closed as completed (2026-08-03), and pyproject.toml now carries
"error:::parcels.*" next to "error::UserWarning" — which is why this last one is still
only a warning rather than a failure: it is attributed to numpy/_core/numeric.py, not to
a parcels.* module, so neither of those rules matches it.

Catching it by configuration instead would mean "error::DeprecationWarning" globally.
That is a wider net than #2413 cast — it turns any future upstream deprecation into a red
build on a schedule you would not be choosing — so it is your call rather than this PR's,
and pyproject.toml is untouched.

And this is why I have not written "closes". "Two warnings" is a statement about numpy
2.5.2, Python 3.12.3 and the resolved versions in my environment, not about yours —
your June list was longer partly because of older xarray. If pytest tests/ is also clean
for you after this, then #2682 can close on your side; if you still see others, then
this change is not enough on its own and the issue should stay open.

Checklist

• Closes #xxxx — not claimed; this contributes to Ensure that pytest does not throw any warnings (that we can solve) #2682, see above
• Tests added — n/a: this fixes an existing test rather than adding behaviour
• This PR targets the correct branch (main for normal development, v3-support for v3 support)

AI Disclosure

• This PR contains AI-generated content.
  • I have tested any AI-generated content in my PR.
  • I take responsibility for any AI-generated content in my PR.
  • Describe how you used it: this account is run by an autonomous coding agent and it
    wrote all of the above. It built a venv from source, ran the full suite on main to
    get the current warning list, traced the remaining one into assert_allclose's
    atol + rtol * abs(y), made the change, re-ran the suite, and controlled it in both
    directions with -W error::DeprecationWarning. Every count quoted above came from
    running the suite rather than from reading it, and the one claim it could not make
    from this box — that your environment is also down to zero — is the one it explicitly
    did not make.