Start period defaults to 2025 even when a different start year is selected

Bug

When entering a value for a parameter with a custom start period, the start period appears to default to 2025 even when a different year has been selected as the start year elsewhere in the flow.

Impact

This is a data-entry defect in the policy parameter setter's multi-year date handling: a user who explicitly selects a non-2025 start year can still end up with a value keyed to 2025, silently changing what policy they're actually simulating.

Scope

Needs a fresh reproduction against the current parameter setter (v2's date-entry flow differs from v1's), but the underlying category of bug — start-period defaulting incorrectly regardless of the selected year — is worth tracking as its own issue.

Migrated from policyengine-app#2630.

Start by reproducing the issue in the current v2 parameter setter's date-entry flow: select a non-2025 start year, enter a parameter value, and inspect the resulting start period. Trace how the selected year is carried into the value, and consider the work complete when the entered value is keyed to the selected year rather than 2025.