docs(examples): correct the after-restore hook deadline

Both SnapStart example READMEs still said the after-restore hook must finish
within the function timeout, which happens to be 10 seconds in these
templates — a coincidence that makes the wrong rule look right. The bound is
Lambda's 10-second Restore phase limit, shared with the readiness check that
follows the hook, and it does not move when the function timeout does.

Follow-up to 9484cef, which fixed the same claim in the README, the guide,
and the source.

Author: bnusunny

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 or a connection failure fails the SnapStart phase. The adapter sets no deadline of its own — the after-restore hook must finish within the function timeout (`10` seconds in this template). 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.
+Both hook routes must return a `2xx` status code. A non-2xx response or a connection failure fails the SnapStart phase. The adapter sets no deadline of its own — but Lambda allows the whole `Restore` phase only [10 seconds](https://docs.aws.amazon.com/lambda/latest/dg/snapstart-troubleshooting.html), regardless of the function timeout, and the after-restore hook shares that window with the readiness check that follows it. 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. A bound above the 10-second `Restore` limit cannot take effect; Lambda times the phase out first.
 
 These hook routes are protected on the Lambda invocation path: the 403 guard lives in the adapter, which only sits in front of your app while it processes Lambda events, so external callers that reach the function (via API Gateway or ALB) and request `/snapstart/before` or `/snapstart/after` receive a `403 Forbidden`. (The guard exists only when the adapter is in the request path — if you run your app without the adapter, protect or don't expose these state-mutating routes yourself.)
 

examples/fastapi-snapstart/README.md

@@ -52,13 +52,16 @@ snapshot boundary:
   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 or a connection
-failure fails the SnapStart phase. The adapter sets no deadline of its own — the
-after-restore hook must finish within the function timeout (`10` seconds here).
-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.
+failure fails the SnapStart phase. The adapter sets no deadline of its own — but
+Lambda allows the whole `Restore` phase only
+[10 seconds](https://docs.aws.amazon.com/lambda/latest/dg/snapstart-troubleshooting.html),
+regardless of the function timeout, and the after-restore hook shares that window with
+the readiness check that follows it. 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. A bound above the 10-second
+`Restore` limit cannot take effect; Lambda times the phase out first.
 
 These hook routes are protected **on the Lambda invocation path**: the 403 guard
 lives in the adapter, which only sits in front of your app when it is processing