fix: #631 Validate planned development date

[ianliuwk1019]

Enforces validation of the DEV_DATE (legacy DEVELOPMENT_DATE) property on FOM spatial file submissions, for cut blocks and road sections. Retention areas (WTRA) are unaffected — they carry no development date.

Previously the field was only loosely checked and had issue - #629.

Changes

Format and calendar correctness (API)

• DEV_DATE uses YYYY-MM-DD format and a real calendar date; strict parsing replaces the previous lenient parse.
• Validation errors now identify the offending feature by its NAME, or by its one-based position in the file when unnamed, so the row can be found in a large submission.

Business range rule (API)

• The date must not be in the past, and its year must be no later than the current year + 7 (3 years FOM validity + 4 years CP validity, applied flat).
• Past and too-far-ahead produce separate messages, each stating the boundary.

Relaxed lower bound for FINAL submissions (API)

• A FINAL submission is measured against the day the PROPOSED submission was created, rather than today, when PROPOSED already contained the same spatial object type.
• Falls back to today when there is no PROPOSED submission, or for a spatial type that was never proposed.

Error dialog readability (Admin)

• The error dialog no longer has a fixed height, so longer validation messages are not clipped.
• Minor punctuation and spacing fix to the 400 Bad Request message.

Behaviour change to be aware of

Validation runs only when a spatial file is submitted. Workflow state changes, the daily state-transition batch, and the cache refresh job do not touch spatial data, so an existing FOM cannot retroactively fail because a date has since moved into the past.

---

Thanks for the PR!

Deployments, as required, will be available below:

• api
• admin
• public

Please create PRs in draft mode. Mark as ready to enable:

• Analysis Workflow

After merge, new images are deployed in:

• Merge Workflow