docs: correct remaining stale 10s readiness bounds in README and example READMEs

Author: bnusunny

README.md

@@ -100,8 +100,10 @@ improperly prepared application.
 
 After restore, the adapter also automatically refreshes its own HTTP connection
 to your application, so it never reuses a connection captured in the snapshot, and
-then re-runs the readiness check before admitting traffic. If the application does
-not report ready within 10 seconds of restore, the restore fails.
+then re-runs the readiness check before admitting traffic. By default this wait is
+unbounded; set `AWS_LWA_READINESS_CHECK_TIMEOUT_SECONDS` (fractional seconds allowed)
+to bound it, in which case a restore whose application does not report ready within
+that timeout fails.
 
 > These hook paths are control-plane operations. External requests (via API
 > Gateway or ALB) that target a configured hook path receive `403 Forbidden` and

examples/fastapi-snapstart-zip/README.md

@@ -24,7 +24,7 @@ To get more information of Wrapper script, please read Lambda documentation [her
   2. `AWS_LWA_SNAPSTART_AFTER_RESTORE_PATH` is set to `/snapstart/after`. The adapter sends an empty HTTP `POST` to this path over the refreshed connection. The app uses it to re-establish connections and regenerate per-environment unique values (in this example, it reconnects the pool and generates a fresh `connection_id`).
   3. It re-runs the readiness check against your app before admitting traffic.
 
-Both hook routes must return a `2xx` status code. A non-2xx response, a connection failure, or taking longer than 60 seconds to respond fails the SnapStart phase. Likewise, if the readiness check does not pass within 10 seconds of restore, the restore fails — so traffic is never served against an app that has not finished recovering.
+Both hook routes must return a `2xx` status code. A non-2xx response, a connection failure, or taking longer than 60 seconds to respond fails the SnapStart phase. The readiness check runs on every restore; by default it waits indefinitely for the app to recover, but you can bound it with `AWS_LWA_READINESS_CHECK_TIMEOUT_SECONDS` (fractional seconds allowed), in which case a restore whose app does not report ready within that timeout fails — so traffic is never served against an app that has not finished recovering.
 
 These hook routes are protected: the adapter only allows them to be invoked internally during the SnapStart lifecycle. External callers that request `/snapstart/before` or `/snapstart/after` receive a `403 Forbidden`.
 

examples/fastapi-snapstart/README.md

@@ -53,9 +53,11 @@ snapshot boundary:
 
 Both hook routes must return a `2xx` status code. A non-2xx response, a connection
 failure, or taking longer than 60 seconds to respond fails the SnapStart phase.
-Likewise, if the readiness check does not pass within 10 seconds of restore, the
-restore fails — so traffic is never served against an app that has not finished
-recovering.
+The readiness check runs on every restore; by default it waits indefinitely for the
+app to recover, but you can bound it with `AWS_LWA_READINESS_CHECK_TIMEOUT_SECONDS`
+(fractional seconds allowed), in which case a restore whose app does not report
+ready within that timeout fails — so traffic is never served against an app that has
+not finished recovering.
 
 These hook routes are protected: the adapter only allows them to be invoked internally
 during the SnapStart lifecycle. External callers that request `/snapstart/before` or