fix(tsa): keep stamping through a grace window after the last good sync

[Bugs5382]

What and why

The TSA clock gate refused every request as soon as one time-sync poll went unanswered, because it looked only at the latest round. A single lost NTP packet took the TSA down until the next good poll.

The gate now trusts the clock for a grace window after the last good sync and refuses with timeNotAvailable only when one of these limits is hit:

Limit	Refused when	Default
no_good_sync	no good sync this boot (also a node with no time source)
adjustment_refused	the servers answered but the clock was not adjusted (sources disagree, step refused); cleared by the next good sync
max_sync_age	the last good sync is older than pki.tsa.max_sync_age_seconds	3600, at most 86400
max_clock_error	the offset at the last good sync plus max_drift_ppm of the time since exceeds max_clock_error_ms	accuracy_ms (1s)

• max_drift_ppm defaults to 100, at most 500 (the NTP frequency tolerance).
• max_clock_error_ms larger than the effective accuracy_ms is rejected by config validation, so a token never claims more accuracy than the clock is trusted to have.
• New proto fields: Tsa.max_sync_age_seconds (8), max_drift_ppm (9), max_clock_error_ms (10) and TimeSyncStatus.adjustment_refused (10). The time-sync engine sets adjustment_refused on answered-but-unapplied rounds and clears it on the next good sync.
• The rejection's statusString names the limit and its value, for example the TSA time source is not available: max_sync_age=1h0m0s exceeded (1h12m3s). Server names and sync errors stay in the node log.
• docs/tsa.md documents the limits, defaults and the accuracy rule. The website companion PR covers the public docs.

Testing

• task ci passes locally (fmt, proto lint, generate verify, lint, vet, test, build).
• Table tests for the gate (window edges, drift crossing the bound, negative offsets, refused rounds, never synced), the error estimate, the responder statusString, config defaults, validation and the proto round trip.

Closes #356