fix(forms): Safari focused none of them, and a board could not make a section

Two reports, one sentence between them: "sections have no function, because you
cannot create more than one."

`autofocus` does not work in Safari for anything inserted after the page has
loaded, and every inline form here is inserted after the page has loaded — rename
a project, add a section, name a group. In Safari they all opened with no cursor
in them and what you typed went nowhere. That does not look like a bug. It looks
like the feature does not work. `use:focusOnMount` replaces all seventeen.

And the board had no way to add a section at all. The button lived only in the
list view, which is the one place nobody looks for it: a column on a board *is* a
section, so that is where you go to make one.

Chasing this turned up a third. The task drawer's three fields save on blur, and
closing the drawer *is* a blur — the input is being unmounted and the browser
fires blur on the way out. If the task left the store in the same moment, `task`
was already null and the handler threw `Cannot read properties of null`, stopping
the page. It only became reproducible once focus actually worked.

Fields are 16px on a touch device now, whatever the component asked for. Below
16px, iOS Safari zooms in when a field takes focus and does not zoom back out —
so the whole interface is left too large and has to be pinched back by hand, once
per field. The type scale tops out at 15px, so every input in the app did it.

The sidebar's resize handle sat at `right: -3px`. An absolutely positioned child
counts towards its container's scrollable overflow, and `overflow-y: auto`
resolves the other axis to `auto` too — so those three pixels gave the whole menu
a horizontal scrollbar on every desktop, always. The account name could do it as
well: `overflow: hidden` with no `min-width: 0` cannot shrink, so the row grew
instead of ellipsing.

There is a WebKit pass in the suite now, over one test. The rest stays Chromium
on purpose — a smoke test exists to catch a build that does not work, and three
engines find the same bug three times — but focus is the exception, and it took a
person using the app to find that out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

web/src/app.css

@@ -407,6 +407,32 @@ button {
 	}
 }
 
+/* Form fields are 16px on a touch device, whatever the component asked for.
+ *
+ * Below 16px, iOS Safari zooms the page in when a field takes focus — and it does
+ * not zoom back out when the field is blurred. The person is left with the whole
+ * interface too large and has to pinch it back themselves, once per field they
+ * tap. The type scale here tops out at 15px, so every input in the app did it:
+ * quick add, the sign-in form, and the task drawer worst of all, which is four
+ * fields deep.
+ *
+ * `!important` on purpose. This is a browser workaround that has to beat every
+ * component's own typography, and each of those is a scoped class that outranks
+ * any selector this file could write. Narrowing it further would mean editing the
+ * sixty-nine places that set a field's font size and adding a rule none of them
+ * can be allowed to break.
+ *
+ * Touch rather than a width: an iPad in Safari does the same thing at a width no
+ * phone breakpoint would catch.
+ */
+@media (hover: none) and (pointer: coarse) {
+	input,
+	textarea,
+	select {
+		font-size: 16px !important;
+	}
+}
+
 .visually-hidden {
 	position: absolute;
 	width: 1px;