docs(hot-reload): honest settle semantics and TTL comment

Micro-fixes from re-review, all text/bound-level, no behavior change to
production logic:

1. settleToBaseline's doc comment (config_hot_reload_test.go) claimed to
   guard the propagation window unconditionally. Reworded: it is a real
   guard on the fired path (two known rebuilds to wait out), best effort
   only on the skip path, where no amount of polling can prove a rebuild
   will never eventually fire — waiting is still required there because
   the earlier disappear-only check was a guaranteed-zero-wait bug, not
   because settling can prove safety on that path.
2. Restored the cleanup settle bound from 20s to 30s, matching the
   longest propagation delay actually observed during verification.
3. README's Config hot-reload intro dropped "on every run" and now
   states the same fired-vs-skip distinction the test's own Skip message
   makes: zero non-200s is blip-free-reload evidence only when the watch
   fires within the test's bound; otherwise it shows just that the stack
   survived an unreloaded rewrite attempt.
4. auth.go's group.cacheTTL field comment still said a positive value
   "overrides it for this group's cache entries only" — reworded to the
   corrected write-time/shared semantics: it sets the TTL written when
   that group's own request populates an entry, entries are shared
   across groups, not scoped by group.

Gate: go build/vet/gofmt clean on both modules; go test ./... -count=1
green.

README.md

@@ -897,8 +897,14 @@ Traefik's exact draining mechanism for requests already in flight on the
 old instance at swap time. What is verified: the integration suite's
 sustained-traffic reload test (`TestConfigHotReload`,
 `integration/config_hot_reload_test.go`) sends requests throughout the
-whole rewrite-and-propagation window and sees zero non-200 responses, on
-every run.
+whole rewrite-and-propagation window and sees zero non-200 responses.
+That result means different things depending on whether Traefik's
+directory watch actually picks up the change within the test's own
+bound. When it does, zero non-200s is evidence of a blip-free reload.
+When it does not — a host-dependent propagation delay, not a plugin
+defect — the same zero-non-200s result only shows the stack stayed
+healthy through an unreloaded rewrite attempt, not that a reload itself
+is blip-free.
 
 A rebuilt instance keeps some state and resets the rest: