feat(i18n): make the visitor form translatable, and stop the template rotting

[ph33nx]

Every form label, help string, section heading and form title was emitted as a raw PHP literal, so none of them reached gettext. They were absent from the POT and from translate.wordpress.org, which meant no language pack could translate them however complete it was. A site set to Spanish rendered an English birth-details form above a correctly translated Spanish reading.

What changed

• bin/generate.mjs wraps visitor-facing strings in __(). TRANSLATABLE_SPEC_KEYS is one list feeding both form emitters — the long tail and the heroes build their spec arrays in separate functions, so a one-sided fix would half-apply.
• name, type and enum stay untranslated deliberately. Enum values are posted verbatim to the API and FormRenderer derives their display text with ucwords(), so translating one would send a translated value.
• The POT is regenerated on every release instead of being hand-maintained; npm run i18n:pot refreshes it locally.

Verification

Check	Result
POT msgids	617 → 861
Birth date, Latitude, Birth details, Western birth chart	now extractable, previously absent
wp i18n make-pot	succeeds
Codegen	idempotent across two runs

test-form-strings-translatable.php scans the emitted source rather than calling spec(): at runtime __() has already returned a plain string, so a translated build is indistinguishable from an untranslated one. It was verified to fail on the previous shape before being relied on.

Verification note

phpcs, phpstan level 8, prettier, lint:js, lint:css, generate:check, check-distignore, build:all and check:blocks pass locally. phpunit and plugin-check need wp-env, which cannot start in that environment, so CI is the gate for those two.