docs(changelog): drop the stale 60-second hook timeout claim

Leftover from before the fixed hook timeout was removed. The changelog was the only
doc still promising a 60s ceiling -- README, the guide and both example READMEs were
updated with the removal, and post_hook documents the opposite contract.

It matters beyond wording: an operator sizing their hook work against a 60s ceiling
that does not exist gets a different failure mode than the real one (hanging to the
Lambda phase bound, which for the after-restore hook is the function timeout).

Author: bnusunny

CHANGELOG.md

@@ -5,10 +5,11 @@
 - Add SnapStart support. The adapter notifies your web application at the SnapStart
   boundary via two opt-in HTTP hooks — `AWS_LWA_SNAPSTART_BEFORE_CHECKPOINT_PATH`
   (before checkpoint) and `AWS_LWA_SNAPSTART_AFTER_RESTORE_PATH` (after restore) —
-  so it can drain and re-establish connections. Each hook call is bounded by a
-  60-second timeout. After restore the adapter refreshes its own HTTP client and
-  re-runs the readiness check before admitting traffic, and it rejects external
-  traffic to the hook paths with 403.
+  so it can drain and re-establish connections. A non-2xx response or a connection
+  failure fails the corresponding SnapStart phase; the adapter sets no deadline of its
+  own, and the after-restore hook must complete within your function timeout. After
+  restore the adapter refreshes its own HTTP client and re-runs the readiness check
+  before admitting traffic, and it rejects external traffic to the hook paths with 403.
   - The crate now stops publishing to crates.io (`publish = false`): Lambda Web
     Adapter ships as the `lambda-adapter` binary (a Lambda layer / copied
     extension), not as a library, so the `lib` target has no external