Fix/362 birthdate not future

[LunarCapsule127]

Why is this change needed?

res.partner.birthdate accepts future dates through every path except the web form. The only guard, _birthdate_onchange, runs solely in the form UI, so ORM create/write, CSV/Excel import, and API writes (XML-RPC, API v2, DCI) all persist a future birthdate. The non-stored age compute then renders that as a negative string (e.g. "-3") in views, exports, and anything reading age. Fixes #362.

How was the change implemented?

Added a stored-field @api.constrains("birthdate") (_check_birthdate_not_future) in spp_registry/models/individual.py. Because birthdate is stored and writeable, the constraint fires on every write path and can't be bypassed. _birthdate_onchange is intentionally kept as the friendlier silent-reset UX in the form; the constraint is the server-side backstop.

New unit tests

Added TestBirthdateNotFutureConstraint in spp_registry/tests/test_constraints.py, covering the paths that bypass onchange — create, write, and load() (import) — plus boundary cases: today must pass, an ordinary past date must pass, and an approximate DOB (birthdate_not_exact) still can't be in the future.

Unit tests executed by the author

Ran via CI on this PR (no local environment available).

How to test manually

In an Odoo shell: env["res.partner"].create({"name": "Test", "is_registrant": True, "birthdate": date.today() + timedelta(days=1)}) should raise ValidationError. Setting birthdate to today or any past date should succeed.

Related links

Closes #362.

A couple of things I'd value your steer on, @gonzalesedwin1123:

Approximate birthdate I've assumed an approximate DOB (birthdate_not_exact) still can't be in the future, and there's a test asserting that. Flagging it as the product decision you noted in the issue in case you'd rather it be exempt.
Existing bad data, the constraint only validates on write, so any records already holding a future birthdate stay invalid until next touched, and would then block otherwise-unrelated writes. Happy to pair this with a data-quality check or a migration note, whichever you'd prefer. Also: the module README regeneration needs the repo toolchain, which I couldn't run locally. Should a maintainer run it, or does CI handle that step?