Justify the handlers tests' start limit with a measurement (closes #225)

The internal/handlers tests were load-fragile because every test app hashed the admin password at 64 MB; that went with the cheaper test hashing already on next, and measuring under the host's real load found nothing left to fix in how the tests run. The comment on newTestApp now says its start limit, fx's default, is there to catch a start that hangs, and that the slowest measured start is far inside it. The header of script/test gives current figures in place of ones from before that change. Neither limit changes, and no test changes.

Model: opus-5-5

internal/handlers/handlers_test.go

@@ -181,6 +181,11 @@ func (r *recordingArchives) Renames() []archiveRename {
 	return out
 }
 
+// newTestApp returns an app whose RequireStart fails the test when
+// starting takes longer than fx's default start timeout of 15s. That
+// limit catches a start that hangs, not a busy host: measured with make
+// test on 2026-10-02 at host load 58-69 on 48 cores, the slowest of this
+// package's starts took 0.49s.
 func newTestApp(
 	t *testing.T,
 	targets ...any,