Fix the edges of the long text limit and height

[PhilReinking]

Long text: an answer of exactly N characters is accepted and N + 1 is refused. "Max characters" and "Height in lines" refuse 0, negative and fractional numbers and say why. A cleared height stays empty. Part of BITS-347 (the answer too long for the database is in a separate PR).

• The textarea has no maxlength: at N + 1 the counter turns red and Submit is disabled.
• A saved 0 or negative max shows as empty, like the public form already treats it.

Tested: Vitest (all 533 pass, 11 new tests fail without the fix), lint, vue-tsc, and by hand on my own server with the editor and the public form.

Not tested: PHP suite (no PHP changes), phone and dark mode.

By hand

Max 0, -5, 2.5: message, no save. Height cleared: saved as null, empty after reload, public textarea has 5 rows. Public form with limit 5: 5 characters fine, 6 gives a red counter and a disabled Submit.

🤖 Generated with Claude Code

[PhilReinking]

Changes at f3e934c, CI green. Must-fix inline: typing -5 or 2.5 still saves "no limit". The rest holds in Brave: a new long text saves 500 once, Scale and Date save their defaults once, a cleared height stays empty and the public textarea has 5 rows, 5/5 is accepted and 6/5 turns red with Submit greyed out. The messages fit at 390 px; the editor has no dark mode. 11 new tests fail on main; Vitest 534 pass.

[PhilReinking]

Typing -5 or 2.5 key by key over a limit of 500 still saves "no limit". The browser reports the half-typed - and 2. as an empty value, and empty means no limit. In Brave at f3e934c the field shows -5 with the message, but the save sends max_chars: null and the reopened field is empty. Height does the same: typing -1 saves the default height. The new tests set -5 in one step, so they miss it.

Treat a half-typed number as invalid: add @input="maxCharsHalfTyped = isHalfTyped($event)" to the Max characters input and @input="rowsHalfTyped = isHalfTyped($event)" to the Height input, then:

Suggested change

	const rowsValid = computed(
	() => isWhole(rows.value) && Number(rows.value) <= 10,
	);
	const maxCharsValid = computed(() => isWhole(maxChars.value));
	// the browser reads a half-typed number like "-" or "2." as empty, which is no clear
	const isHalfTyped = (event: Event) =>
	(event.target as HTMLInputElement).validity.badInput;
	const rowsHalfTyped = ref(false);
	const maxCharsHalfTyped = ref(false);
	const rowsValid = computed(
	() => !rowsHalfTyped.value && isWhole(rows.value) && Number(rows.value) <= 10,
	);
	const maxCharsValid = computed(
	() => !maxCharsHalfTyped.value && isWhole(maxChars.value),
	);

With this, typing -5 keeps 500 and -1 keeps 5 (checked in Brave). Vitest (with the clear tests), lint and vue-tsc pass.

[PhilReinking]

OK at 313c519, CI green. The must-fix holds in Brave: typing -5 keeps 500, -1 keeps height 5, and deleting a half-typed "-" saves "no limit" or the default height; 500 → 800 still saves. Not blocking: typing 2.5 over 500 saves 2, because the save queued for the "2" on the way still goes out (like 11 → height 1). Fixing that needs the store's save queue, so a follow-up. Vitest 537 pass.