fix: anchored times shift only while still running at save start (#2730)

Follow-up to #2729.

## Problem

At load, `ReadAnchoredTime` shifted **every** anchored value forward by the downtime, including values that were already in the past when the save started. That caused two problems.

**An expired deadline came back.** A deadline that passed 5 minutes before a 30-minute outage loaded 25 minutes in the future. For example:
- `Sheep.NextWoolTime`: a sheep that was ready to shear stopped being ready.
- `PlayerVendor.NextPayTime`: an overdue payment was pushed back.
- `BaseCreature.SummonEnd`, the spell fields' `End`, `TransientItem.Expiration`, and the ChampionSpawn times could move the same way.

**Records were rewritten for nothing.** The first save after every restart rewrote:
- stamps of things that had already happened: VirtueContext's `LastHonorUse`, `LastSacrificeGain`, the four `Last*Loss` stamps, and `Corpse.TimeOfDeath`
- every deadline that had expired long ago.

## Change

- **`IGenericReader.AnchoredTimeOrigin`** is the loaded save's start time.
  - `GenericEntityPersistence` and `GenericPersistence` set it from `World.LoadedSaveStartTime`.
  - `BufferReader`, `UnmanagedDataReader` and `BinaryFileReader` expose it.
- **`ReadAnchoredTime` returns any value at or before the origin exactly as saved.**
  - A deadline still running at save start is shifted as before and keeps its remaining time.
  - Readers without an origin keep the old behaviour.
- **This covers every anchored field, including generated ones.** Generated `[AnchoredDateTime]` fields call `reader.ReadAnchoredTime()`, so the one change covers all 26 generated fields as well as the manual reads. `[DeserializeTimer]` only restores timers that were running at save time, so it is unaffected.
- **The `[AnchoredDateTime]` section of `dev-docs/serialization.md` and the `WriteAnchoredTime` doc comment describe the new rule.**

## Behaviour change

Downtime now counts toward windows measured from a past stamp:

| Window | Length |
|---|---|
| Honor use | 5 minutes |
| Sacrifice gain | 1 day |
| Virtue atrophy | 7 days |
| Instanced corpse looting | 3 minutes |

A 30-minute outage makes a 7-day atrophy fire about 0.3% sooner. No format change.

## Tests

New tests in `AnchoredTimeTests`:
- A deadline running at save start keeps its remaining time.
- A deadline that passed before save start stays passed.
- A past stamp is not shifted.
- A value exactly at save start is not shifted.

`Server.Tests`: 845 passed. `UOContent.Tests`: 1140 passed.

dev-docs/serialization.md

@@ -261,14 +261,17 @@ Best for fields that are usually small values (counts, IDs, indexes).
 ### [AnchoredDateTime]
 
 **Target**: `DateTime` field
-**Effect**: Stores the absolute UTC instant; at load it is shifted forward by the downtime
-between the save and the load (using the save-start anchor in the save's index file), so
-server downtime does not consume the remaining time. `DateTime.MinValue`/`MaxValue`
+**Effect**: Stores the absolute UTC instant. At load, a value still in the future when the save
+started is shifted forward by the downtime between the save and the load (using the save-start
+anchor in the save's index file), so server downtime does not consume the remaining time. A
+value at or before the save start is loaded as saved: an expired deadline stays expired, and a
+"last happened at" stamp lets downtime count toward its window. `DateTime.MinValue`/`MaxValue`
 sentinels pass through unshifted.
 
-Prefer this for deadlines and "elapsed while running" values. Unlike `[DeltaDateTime]`, the
-stored bytes do not change on every save when the value is unchanged, keeping idle saves
-byte-stable.
+Use this for deadlines. A field that only records when something happened (a last-use stamp)
+never shifts, so it may equally be a plain `DateTime`. Unlike `[DeltaDateTime]`, the stored
+bytes do not change on every save when the value is unchanged, and only deadlines still running
+at save time change across a restart.
 
 ```csharp
 [AnchoredDateTime]