docs: correct the form-trigger design doc's account of the body cap

The "What is missing" section claimed uploads were unbounded, citing
CPPHTTPLIB_PAYLOAD_MAX_LENGTH's SIZE_MAX default. That was never true
in this codebase: HttpServer already called set_payload_max_length()
with a hardcoded 16 MB literal. Correct the paragraph to describe what
was actually there - a hardcoded 16 MB HTTP-layer cap plus a separate,
lower 4 MB gRPC-layer cap between the webserver and runner - and that
the fix makes both configurable and raises the default to 32 MB for
image uploads.

docs/superpowers/specs/2026-08-09-form-trigger-design.md

@@ -42,11 +42,18 @@ arrive as a string that is not valid UTF-8. httplib 0.18.3 does expose
 `req.files` and `is_multipart_form_data()`, so this is wiring rather than
 invention.
 
-**Uploads are unbounded.** `CPPHTTPLIB_PAYLOAD_MAX_LENGTH` is
-`(std::numeric_limits<size_t>::max)()` by default and the body is buffered whole
-in memory. Every existing public webhook is therefore a memory-exhaustion
-endpoint, not only the new form ones. This design fixes that because it must,
-not because forms introduced it.
+**Uploads were bounded, but by an unconfigurable, disagreeing pair of caps.**
+`HttpServer` already called `set_payload_max_length()` with a hardcoded 16 MB
+literal where it constructs `httplib::Server`, and separately the runner's
+own gRPC server accepted at most the grpc++ default of 4 MB per message -
+lower still, and reached only after the HTTP layer had already accepted the
+body. Neither number came from config, and neither was raised with the other
+in mind. Task 2 makes both configurable (`server.max_upload_mb` on the
+webserver side, the existing `max_message_size_mb` on the runner side, now
+also applied to the runner's own gRPC server rather than only to its
+database client) and raises the shipped default to 32 MB, because an upload
+node needs to carry up to a 16 MB image field, and that field cannot fit
+inside a 16 MB total body once multipart framing is added on top.
 
 **One node must answer two verbs.** A form is a GET that renders and a POST that
 submits, so the method mapping above cannot express it.