Follow-ups from docs#77: stale line locators next to the edited shutdown text, and the uncommitted docs probe

[FumingPower3925]

Follow-ups from the review of goceleris/docs#77 (#738's docs PR). None blocks the merge. The blocking findings were fixed in docs#77 round 2.

Handled in round 2:

• "a Start stopped by Shutdown" was not measured (nit). Round 1's probe only started servers with StartWithContext. The round-2 probe measures Start + direct Shutdown too, reading every call's return concurrently. Round 1's probe read Start's return only after Shutdown had returned, which is how the false std claim got in.

Open:

1. Stale line-number locators next to the edited text. Cite symbols, as the rest of graceful-shutdown.md now does:
   • deployment.md:504 cites celeris/server.go:681-699 for StartWithListener, and its sentence there does not mention that since fix(server): a Start that never serves releases the caller's listener, the CPU monitor and the settle re-opener (#737) #747 a failed start closes the listener.
   • deployment.md:598 cites celeris/server.go:693-751.
   • graceful-shutdown.md:434 cites celeris/resource/config.go:152-161 for the Addr/Listener ambiguity check, which is at resource/config.go:216-225 at fix(server): Shutdown runs the OnShutdown hooks, and returns, only after the drain on every engine (#703) #746/fix(server): a Start that never serves releases the caller's listener, the CPU monitor and the settle re-opener (#737) #747's heads.
   • Wider: grep -c 'server.go:[0-9]' gives deployment.md 4, configuration.md 6. configuration.md also cites many config.go: and resource/config.go: ranges. Follow-ups from docs#73: the graceful-shutdown pages say a cancel behaves identically on every engine, and that ShutdownTimeout bounds only the hooks #738 item 3 named graceful-shutdown.md only, so this is new scope.
2. The FAQ numbers come from a probe that is not committed anywhere public. round2/738/docs_probe_linux_test.go lives in the lane's evidence root, which is not version-controlled, so nobody else can re-run it from the PR. Commit it (a docs-verification test in probatorium, or an example test in celeris), or say in the page that the numbers are maintainer-measured.

[FumingPower3925]

More follow-ups from goceleris/docs#77. CodeRabbit reviewed the PR when it left draft, at head 5b463a1. All seven findings are minor, so the PR merges without them (review cap). Line numbers are at 5b463a1.

Open:

3. deployment.md:537 cites celeris/server.go (StartWithContext). CodeRabbit says the path is repository-root server.go (thread). The celeris/ prefix is the site's convention for the celeris repo (deployment.md:600 has celeris/server.go:693-751). Settle it in item 1's locator sweep, site-wide, rather than on one line.
4. deployment.md:617-622, the Kubernetes sequence and grace-period formula.
   • "In-flight requests drain within ShutdownTimeout" reads as a guarantee. At the deadline Celeris stops waiting; it does not finish the requests (graceful-shutdown FAQ, "What happens to requests still running when the deadline expires?") (thread).
   • "terminationGracePeriodSeconds > readiness delay + ShutdownTimeout" covers the hooks only when every hook returns once its ctx is done: a hook that ignores ctx is not interrupted. It does not cover std's cancel path until std: a cancel of StartWithContext's context ignores Config.ShutdownTimeout; the drain, the OnShutdown hooks and Start wait for every handler #753 is fixed, because there the hooks wait for the handler (thread).
5. getting-started.md:191-192, the code comment "returns after the in-flight requests have drained and then the OnShutdown hooks have run". At the deadline the hooks run while a request is still in flight. The drain also skips the HTTP/2 streams listed in graceful-shutdown's "What the drain waits for" (HTTP/2 streams on the shared H2 worker pool are not drained at shutdown: an async-route stream loses its response on epoll, io_uring and adaptive, and std waits for no h2c stream #759). The paragraph below the example covers the deadline but not the HTTP/2 gap (thread).
6. The std cancel-path exception (std: a cancel of StartWithContext's context ignores Config.ShutdownTimeout; the drain, the OnShutdown hooks and Start wait for every handler #753) is missing wherever a page calls ShutdownTimeout one budget: getting-started.md:201-203, configuration.md:215-221 and deployment.md:536-538. graceful-shutdown.md states it (thread).
7. graceful-shutdown.md:658-660, the FAQ line "its response still reaches the client when it finishes". It gives epoll's unflushed close (epoll: shutdown closes connections with their pending writes unflushed, so a response larger than the socket buffers loses its tail (no counterpart of io_uring's #595 send drain) #760) as an exception but not the async HTTP/2 streams on epoll, io_uring and adaptive. The drain does not wait for those streams, and they lose their response (HTTP/2 streams on the shared H2 worker pool are not drained at shutdown: an async-route stream loses its response on epoll, io_uring and adaptive, and std waits for no h2c stream #759). Add them, or point both exceptions at "What the drain waits for" (thread).

Checked and refuted, no change:

• graceful-shutdown.md:661-662, "c.Context() is not cancelled at the deadline" (thread). CodeRabbit says std cancels it. On std, Engine.Shutdown does cancel baseCtx when its ctx expires. But baseCtx is the parent of r.Context(), and a handler's c.Context() is not r.Context(). The std bridge builds each request on stream.NewH1Stream, acquireContext sets c.ctx = s.Context(), and Stream.Context() returns the package's context.Background() for an H1-mode stream (protocol/h2/stream/stream.go, at celeris dfd044f). r.Context() reaches only the OnWSDetachClose hook. The round-2 probe measured c.Context() done "never" on std as well.