docs: explain why the extension long poll never resolves

The extension registers with `{"events": []}` and then parks on
GET /2020-01-01/extension/event/next forever. Nothing said why, so the standing
question "the long poll is not re-established after a SnapStart restore -- is that
a leak or a crash risk?" kept coming back.

It is neither, and the empty events list is the reason. Being registered at all is
the entire point: Lambda only delivers SIGTERM at environment shutdown when an
extension is registered, which is what the graceful-shutdown feature relies on.
Subscribing to nothing means RAPID has no event to deliver, so the long poll is
never going to resolve -- parking on it IS what keeps the extension alive.

Under SnapStart that request is captured mid-flight in the snapshot and never
re-established, which is harmless for the same reason, and RAPID's registration
state is part of the snapshotted microVM so the effect survives even though the
connection does not.

Verified on a deployed SnapStart container function: the restored environment
received SIGTERM 457s after restore, in the same log stream that logged
after_restore, and the failure path that would exit(1) never fired across ~8
minutes and five restores. A non-SnapStart control on $LATEST behaved identically
apart from the clocks (monotonic_delta == wall_delta on a normal cold start, versus
0.38s against 184.3s across a restore).

Re-registering after restore would be robustness, not a fix.

Comment-only; no behavior change.

Author: bnusunny

src/lib.rs

@@ -1248,6 +1248,23 @@ impl Adapter<HttpConnector, Body> {
     ///
     /// Registers with the Lambda Extensions API and waits for the next event.
     /// This keeps the extension alive for the duration of the Lambda instance.
+    ///
+    /// The registration subscribes to **no events** (`{"events": []}`), deliberately.
+    /// Being registered at all is the entire point: Lambda only sends `SIGTERM` at
+    /// environment shutdown when an extension is registered, which is what the
+    /// graceful-shutdown feature relies on. Because nothing is subscribed, RAPID has
+    /// no event to deliver, so the `GET /event/next` call below never resolves — the
+    /// spawned task parks on it for the life of the process by design, and that is
+    /// what "keeps the extension alive".
+    ///
+    /// Under SnapStart that parked request is captured mid-flight in the snapshot and
+    /// is never re-established after a restore. That is harmless for the same reason:
+    /// it was never going to resolve, and RAPID's *registration* state is part of the
+    /// snapshotted microVM, so the effect survives even though the connection does
+    /// not. Verified on a deployed SnapStart container function — the restored
+    /// environment received `SIGTERM` 457s after restore, and the failure path below
+    /// (which would `exit(1)`) never fired across ~8 minutes and five restores.
+    /// Re-registering after restore would be robustness, not a fix.
     async fn register_extension_internal() -> Result<(), Error> {
         // Prefer the original (pre-proxy) value if apply_runtime_proxy_config() captured one.
         // Otherwise fall back to the current env var.