AddAsync/GetAsync/UpdateExpiryAsync throw on a DateTimeOffset expiry at or near now

Found while reviewing #664. Pre-existing on master, not introduced by that PR.

Symptom

AddAsyncDateTimeOffset_WithTags_CorrectTaggedKey_Async passes as part of the full suite but fails when run in isolation:

dotnet test -f net10.0                      # 1754/1754 pass
dotnet test -f net10.0 --filter "FullyQualifiedName~AddAsyncDateTimeOffset_WithTags_CorrectTaggedKey_Async"
# 6 of 7 serializer variants fail, reproducible across runs

Only the first serializer variant passes; the rest fail consistently, which points at state left behind by whichever test ran before rather than at timing.

Why it matters

Test parallelization is disabled and all tests share one Redis instance, so this kind of coupling stays invisible until someone runs a filtered subset — exactly what you do when debugging a single failure. It also means a green full-suite run is not proof that the test actually asserts what it claims.

Likely cause

The tag Set key is probably not fully cleaned between variants, so the assertion passes on residue from a previous test rather than on what the test itself wrote. Worth checking the FlushDbAsync placement in CacheClientTestBase against the tag-related keys.

Acceptance criteria

• The test passes both in the full suite and when run alone with --filter
• Any sibling tag tests with the same coupling are fixed alongside it

Start with AddAsyncDateTimeOffset_WithTags_CorrectTaggedKey_Async and inspect FlushDbAsync placement in CacheClientTestBase, then run the full test and the provided filtered command. Check whether tag Set keys remain between serializer variants and inspect sibling tag tests for the same coupling. Done means the test passes alone and in the full suite, with affected sibling tests also isolated.