Route GORM's logger through slog and bound it (closes #178)

GORM's default logger printed the fully interpolated SQL to standard
output on every statement that returned an error, including a plain
record-not-found. On /webhook/{uuid} and on the login form the
interpolated parameter is client-chosen and unbounded, so an
unauthenticated client sized the operator's log, one line per request,
at no level the operator could turn down.

Every gorm.Open in the service now installs internal/gormlog, a
gormlogger.Interface over the service's *slog.Logger. Its lines take
the level the operator set and the handler internal/logger selected; a
record-not-found is not logged as an error, since it is the expected
outcome on both of those paths and each handler already records its
own miss at DEBUG without the SQL; slow statements are kept at WARN
above the same 200ms threshold GORM used; and every value it emits is
spent through internal/logfield, the same encoded-byte budget the
access log spends. MaxAccessLogLineBytes bounds a GORM line too, and
internal/gormlog asserts each line against the constant directly.

Trace orders its cases exactly as GORM's own Trace orders them --
error-that-is-not-a-miss, then slow, then routine -- so a statement
that both missed and ran slow is still reported as slow. Ordering the
drop first would have made this adapter strictly less observant than
the IgnoreRecordNotFoundError option it was chosen over, on the two
lookups the issue is about, and a miss is the statement most likely to
be slow.

The third gorm.Open, in the archive writer, was not named in the issue
and had the same default. All three sites are pinned independently:
internal/handlers covers the main and per-webhook databases,
internal/delivery covers the archive writer, whose type is unexported.
Reverting any one of the three to a bare &gorm.Config{} fails the
suite.

The flood test's per-line and volume assertions were vacuous, because
the replaced default logger wrote only to a buffer while everything
else went to the captured stdout. It now tees to stdout as GORM's real
default does, so a reverted call site lands in the same capture and
those assertions measure the whole writer set.

internal/logfield gains the zero-headroom budget assertion and the
rune-splitting case: a value built from one rune must keep exactly
MaxBytes/EncodedBytes(r) of them, which a raw-byte budget fails and a
LessOrEqual on the budget cannot catch.

README: the ceiling now covers GORM, and the writers it does not cover
are re-derived by measuring rather than by reading. fx's console
logger and the Go runtime write to standard error. net/http's nil
ErrorLog is not a separate writer at all -- slog.SetDefault redirects
the log package's default logger into internal/logger's handler, so
those lines arrive on standard output at INFO. A handler panic reaches
that same path because chi's Recoverer crashes before writing, filed
as #187, and is the widest
line the service can write: measured at roughly 2,770 bytes against
the stated 2,560, a width that moves with the goroutine number and the
source paths in the stack, so only the fact that it exceeds the
ceiling is stated as invariant.

internal/middleware/middleware.go

@@ -67,6 +67,9 @@ const (
 	//	                                        ----
 	//	                                        2087
 	//
+	// The 512 is logfield.MaxBytes; the 11 is the truncation marker,
+	// charged on top of each budget rather than inside it.
+	//
 	// The fixed portion is the JSON punctuation, the field names, the
 	// level and the message, both timestamps at their longest, an IPv6
 	// remoteIP with a zone, a three-digit status and a full-width int64
@@ -104,6 +107,17 @@ const (
 	// a caller on a parameterised route would supply, which is the
 	// only way those caps can be pinned at all.
 	//
+	// One writer in that set is not a handler's own slog call. The
+	// GORM adapter in internal/gormlog logs the statement with the
+	// client-chosen parameter already interpolated into it, which on
+	// the receiver and login lookups is exactly the value the budgets
+	// above exist for. Its widest line spends two logfield.MaxBytes
+	// budgets — the statement and the driver error — against a fixed
+	// portion smaller than this one's, and
+	// internal/gormlog/gormlog_test.go asserts every line it emits
+	// against this constant directly rather than leaving it as
+	// arithmetic.
+	//
 	// What it does NOT cover, so that the figure above is not read as
 	// more than it is:
 	//
@@ -119,10 +133,16 @@ const (
 	//   - The "log" delivery target, which exists to write the whole
 	//     inbound event to the log. Deliberate; see
 	//     internal/delivery/target_log.go.
-	//   - GORM's default logger, which prints the interpolated SQL to
-	//     stdout on a record-not-found and so is unbounded on the
-	//     receiver and login lookups. NOT deliberate; filed as
-	//     https://git.eeqj.de/sneak/webhooker/issues/178.
+	//   - The widest line the service can write, which is neither an
+	//     access log line nor client-chosen. A handler panic arrives
+	//     through net/http's nil ErrorLog as one record carrying a
+	//     whole goroutine stack, above this figure — measured at
+	//     roughly 2,770 bytes. The exact width is not an invariant: it
+	//     moves with the goroutine number and with the source paths
+	//     baked into the stack. That it exceeds this ceiling does not
+	//     move. The value is the runtime's, not a client's; see
+	//     README.md and
+	//     https://git.eeqj.de/sneak/webhooker/issues/187.
 	MaxAccessLogLineBytes = 2560
 )