Implement input validation for Equipment entry on web interface

[brickbots]

The web interface allows inputs to be sent to the API that will write data for equipment that will cause issues. These can be simple UI issues (like a blank telescope name), crashes, and other UX problems.

The task for this issue is to come up with the rules for what can go into each field (string, integer, float) and what the validation rules are. Then to codify these in the equipment context docs, implement checks in the web UI front end and the API back end, then to set up tests to assure that invalid inputs are caught via the front-end so the user has good feedback and stopped at the API level to avoid writing config values that will cause UX issues.

[brickbots]

Ran the Selenium web suite plus a manual API pass against main @ 4a83d25b today as part of 2.6.1 Gate 6, and turned up concrete evidence for this issue — plus a sibling defect on the GPS form with the same root cause. Recording it here so the validation rules get designed against real failure modes.

The equipment forms fail silently, which is worse than crashing

Both equipment handlers wrap their parsing in except Exception: logger.error(...) and then fall through to render the success template anyway. Reproduced live:

POST /equipment/add_eyepiece/-1   focal_length_mm=7,5   field_stop=8,0
  → HTTP 200 + banner "Eyepiece added, restart your PiFinder to use"
  → eyepiece count unchanged (3 → 3). Nothing was saved.

The user is told it worked. Same pattern in equipment_add_instrument with the "Instrument Added" banner. So alongside the validation rules this issue asks for, the API-level behaviour needs fixing independently: a handler that fails must not render the success path. That's arguably the highest-value single change here.

A decimal comma is the easiest trigger (PiFinder ships de/es/fr/zh, and these fields are type="text" inputmode="decimal", so the browser doesn't normalise), but anything non-numeric does it — including the blank-name case in the issue description.

There is already a correct helper; almost nothing uses it

parse_coordinate() (python/PiFinder/server.py:51) accepts comma or period and raises a translated "%s must be a number". Only two call sites use it — /locations/add (:372–378) and /locations/rename (:432–438). Everything else parses raw:

Location	Code	Failure mode
server.py:738,740	float(focal_length_str), float(field_stop_str), int(afov_str)	Silent — caught at :754, success banner still shown
server.py:821–823	int(aperture_str), int(focal_length_mm), float(obstruction_str)	Silent — same, "Instrument Added"
server.py:647	float(obstruction_perc) (DeepskyLog import)	JSON-sourced, so comma unlikely — a string-typed field still 500s
server.py:690,692	float(eyepiece["focalLength"]), float(eyepiece["field_stop_mm"])	as above
server.py:343	gps_lock(float(lat), float(lon), float(altitude))	Unhandled 500 — see below

Current field types, as a starting point for the rules

Straight from the dataclasses in python/PiFinder/equipment.py:

	Field	Declared type
Eyepiece	focal_length_mm	float
	afov	int
	field_stop	float (default 0)
Telescope	aperture_mm	int
	focal_length_mm	int
	obstruction_perc	float

Worth settling as part of this issue: focal_length_mm is float on Eyepiece but int on Telescope. Same field name, two types. A 2000.5mm scope is currently unrepresentable while a 7.5mm eyepiece is fine. Also undecided: whether these are bounded (negative aperture? obstruction_perc > 100?) and whether make/name may be blank — the blank-telescope-name case in the description has no guard today.

Sibling defect on the GPS form — scope decision needed

Same root cause, different endpoint, and this one is user-visible as a hard failure:

POST /gps/update  latitudeDecimal=51,3  → 500   (location unchanged)
POST /gps/update  latitudeDecimal=51.5  → 302   (identical values, succeeds)

gps_update() has no try/except at all, so float() raises straight through to a 500. #536 fixed this class for /locations — its normalizeDecimal helper is used 6× in views/locations.html but appears zero times in views/gps.html. /gps is reachable from the home page (views/index.html:22, the edit pencil beside the location row), so comma-locale users hit it on the primary location editor.

Secondary, same file family: views/locations.html:282,288 call decimalToDMS(parseFloat(...)) without the normalizer that the reverse direction (:235–237) uses correctly — so typing 51,3 renders DMS as 51° 0' 0", and touching any DMS field then writes 51 back over the decimal, silently dropping the .3.

This is outside this issue's equipment title. Either widen #569 to "numeric input validation across the web forms" — they'd share one helper and one test approach — or split the GPS half into its own issue. Happy either way; flagging rather than assuming.

Notes for whoever picks this up

• Full write-up with line numbers, the three sites that look wrong but are fine, and a suggested fix order: handoff doc at /tmp/pifinder-comma-decimal-handoff.md.
• Gate 6 results and acceptance wording: release_notes/release-2.6.1-test-plan.md §7 (G6.2) and §8.
• Test at the request level, not through Selenium. The web suite runs en-US and structurally can't catch decimal-comma bugs (that's how fix(web): accept comma or period decimal separator when saving locations #536 shipped), and it doesn't run in CI. A Flask test-client POST of 7,5 is a few lines and does run in CI.
• No existing regression test covers any of these paths. Unit+smoke baseline is 1,159 passing at 4a83d25b.