Add academic_year period type to the source-package contract

[juaristi22]

Lane: ledger-contract-maintainer (.github/ledger-agents.yml) — judges ledger-contract + ledger-boundary
Blocks: #132 (wave-1 SLC student-support package) and #133 (slc_repayments)

Context

UK student-finance publications (SLC / DfE Explore Education Statistics) publish by academic year. The committed package vocabulary today is calendar_year (~1,192 record sets), tax_year (~191), fiscal_year (~133), month (3) — there is no way to state what the SLC publisher actually asserted, and re-labelling AY 2024/25 as a calendar or fiscal year would misstate the source.

This is the only contract change the UK target migration needs. It is deliberately its own issue, isolated from the data waves, so no source-package PR drags through contract review.

Scope

• ledger/source_package.py period-type validation, plus the policyengine_ledger consumer-schema surfaces that enumerate period types
• docs/schemas/ update, including the period-integer convention: the starting year (AY 2024/25 → period: 2024), matching how fiscal_year FY2024–25 is stored as 2024. Any downstream AY→calendar alignment (policyengine-uk-data maps 2024/25 → 2025) is a consumer concern, not a fact property.
• Tests: schema validation plus a round-trip through build-consumer-artifact proving the consumer contract resolves academic_year rows.

Acceptance

• academic_year record sets validate, build, and resolve through the consumer contract.
• Deterministic checks green: schema validation, consumer-contract validation, package import compatibility, raw-facts boundary validation.
• No existing package's behavior changes.