Send fx's own events through the service's logger (closes #183)

fx printed its dependency graph and its start and stop hooks through
its console logger on standard error. fx.WithLogger now hands those
events to the service's logger: building the graph at DEBUG, the hooks,
the start and the stopping signal at INFO, failures at ERROR. The fx
logger's constructor takes the configuration, so the level DEBUG=true
sets is in force before fx replays the events it held back. fx's
SlogLogger takes one level for everything that is not a failure, so
FxLogger in internal/logger holds one at each level. fx moves from
v1.20.1, which has no SlogLogger, to v1.24.0. The README names the Go
runtime as a writer whose output cannot be redirected.

Model: opus-5-5

README.md

@@ -544,8 +544,8 @@ If it is lost, run `webhooker resetpw admin` on a stopped deployment.
 ```
 
 It is a banner rather than a log line because that is the only time it
-is ever shown: as one `INFO` record it sat among the roughly 45 fx
-`PROVIDE`/`RUN`/`HOOK` lines a boot writes, and under `docker run -d`
+is ever shown: as one `INFO` record it would sit among the records fx
+writes as each start hook runs, and under `docker run -d`
 it is one line in a log subject to rotation. The database stores only
 its Argon2id hash. There is no second account and no forgot-password
 flow, so the banner and the reset command below are the only two ways
@@ -615,7 +615,8 @@ Changing a password you still know needs none of this — use
 
 `DEBUG=true` lowers the log level to `DEBUG`, which turns on every
 statement GORM runs, the two by-design lookup misses on the
-unauthenticated routes, and the rate limiter's own rejections. It is
+unauthenticated routes, the rate limiter's own rejections, and fx's
+records of building the dependency graph at startup. It is
 meant to be safe to turn on while diagnosing a live service and safe to
 paste the output of into a bug report.
 
@@ -2624,16 +2625,15 @@ read as more than it is:
   that type on a specific webhook, and each line it writes is bounded
   per event by the 1 MB receiver body cap. Adding one is a decision to
   spend log volume on that webhook's payloads.
-- **Two writers that do not go through `internal/logger` at all**, both
-  on standard error. `fx` prints the dependency graph and the lifecycle
-  hooks through its default console logger at startup and shutdown —
-  nothing calls `fx.WithLogger`, and `fx.New` builds that logger over
-  `os.Stderr`. The Go runtime writes a panic or a fatal error itself; a
-  panic in a background worker rather than in a request handler is the
-  case that reaches it, since nothing recovers those. Neither carries a
-  client-chosen value at a client-chosen length: the five `panic` calls
-  in this service are invariant guards over constants and over
-  `crypto/rand`.
+- **The Go runtime**, which does not go through `internal/logger`. The
+  runtime writes an unrecovered panic or a fatal error itself, as plain
+  text on standard error, and that output cannot be redirected. A panic
+  in a background worker rather than in a request handler is the case
+  that reaches it, since nothing recovers those. It carries no
+  client-chosen value at a client-chosen length: the service's own
+  `panic` calls are invariant guards over constants and over
+  `crypto/rand`, apart from the one that hands `http.ErrAbortHandler`
+  back to `net/http`, described below.
 - **`net/http`'s own faults**, which are _not_ a separate writer.
   `internal/server/http.go` builds its server with a nil `ErrorLog`, so
   `net/http` falls back to the `log` package's default logger — and
@@ -2983,7 +2983,7 @@ webhooker/
 │   ├── lifecycle/
 │   │   └── lifecycle.go       # Shared stop-hook waiter, bounded by the stop context
 │   ├── logger/
-│   │   └── logger.go          # slog setup with TTY detection
+│   │   └── logger.go          # slog setup with TTY detection; fx's event logger
 │   ├── metrics/
 │   │   └── metrics.go         # Delivery Prometheus collectors, labelled by target type
 │   ├── middleware/