fix: form submission reliability — reCAPTCHA timing, error handling, logging (v1.0.5)

[johannesparty]

Summary

Fixes several contact-form reliability issues surfaced while diagnosing "Unable to send message" / stuck-on-"Sending…" reports, and adds diagnostics so future failures are self-explanatory in the log.

Changes (one commit each)

• Airtable logging (class-bd4d.php): log the real HTTP status and the Airtable response body on send failure. The prior "success" line fired for any completed request regardless of status, and the non-200 failure branch logged nothing — making failures undiagnosable.
• reCAPTCHA verify hardening (class-google-recaptcha.php): add a 10s timeout and log HTTP/JSON errors plus the full Google result (success, score, action, error-codes) on failed verification.
• Frontend reliability (main.js + built assets):
  • Generate the reCAPTCHA v3 token at submit time instead of page load. v3 tokens expire ~2 min after generation, so page-load minting caused intermittent failures for slower form-fillers.
  • Add an AJAX error/timeout handler (30s) so failed submissions show an error instead of hanging on "Sending…".
• Docs (README.md): add a "Rotating the Airtable Token" runbook (diagnose the 403 INVALID_PERMISSIONS_OR_MODEL_NOT_FOUND, issue a new PAT scoped to the base, verify).
• Version bump to 1.0.5.

Root causes found during investigation

1. The live Airtable Personal Access Token had lost access to the base (owned by a departed account) → all submissions 403'd. Fixed operationally by issuing a new token; this PR adds the logging that pinpointed it.
2. The frontend had no AJAX error handler, so any failure (including the cached-page nonce 403 seen when testing while logged into wp-admin) hung the button silently.

Test plan

• Anonymous/private-browser submission succeeds → debug.log shows Airtable API responded HTTP 200.
• After deploy: confirm a forced failure surfaces an error message instead of hanging on "Sending…".
• After deploy: confirm reCAPTCHA no longer fails for slow submissions.

Deployment notes

• Built assets (main.min.js etc.) are committed — no rebuild needed at deploy.
• Merge uses squash/rebase (linear history enforced on main).

🤖 Generated with Claude Code