Date pickers created inside @for never bind, and share one ID across rows

[Aman-Mittal]

Found while broadening the e2e coverage for #541. Two distinct defects in the same markup, both pre-existing and neither addressed by the #546/#547 fix.

1. A picker created after the first render never binds

floating-rate-form.component.ts renders its date controls inside @for (period of periods(); track $index), so they are created when the user clicks Add Period, not with the page.

ion-datetime-button resolves its target ion-datetime exactly once, in componentWillLoad, through a global getElementById, and gives up for good when that lookup misses. The button and the ion-modal[keepContentsMounted] that holds its picker are created in the same change-detection pass, and the modal's contents are not in the DOM yet when the button initializes. The control renders blank and never opens.

Unlike #541 this needs no revisit — it fails on the first visit, as soon as a period is added.

createPickersReady() does not help here. It gates the initial render, and by the time a row is added the flag is already true, so the new row's button is created immediately alongside its modal. Verified:

• with the @if (pickersReady()) wrapper removed (the pre-fix shape), the picker fails identically — so this is not a regression from fix(ui): keep date pickers usable on every routed form visit #547, just a case that fix does not reach
• moving <ion-modal> before <ion-datetime-button> in the row does not help either; the modal's contents still are not in the DOM in that pass

A per-instance deferral is needed — something that defers each button relative to its own creation rather than the page's, which likely means a small wrapper component owning the button, modal and picker together.

2. Rows share a single picker ID

Within that same @for, the ID is a constant:

<ion-datetime-button datetime="periodfromDate-picker"></ion-datetime-button>
...
<ion-datetime id="periodfromDate-picker" data-testid="periodfromDate-picker" ...>

Two rate periods therefore put two elements with id="periodfromDate-picker" in the document. getElementById returns the first, so every row's button points at the first row's picker — editing period 2's date would edit period 1's. This is the ID-collision problem discussed in #544, in a place where it actually bites rather than staying latent. The ID needs to vary per row.

Reproduce

1. Go to /products/floating-rates/create
2. Click Add Period
3. The From Date control renders blank and does not open
4. Add a second period — both rows' controls target the same picker

Coverage

e2e/date-picker-revisit.spec.ts covers this page with test.fail(), so the suite asserts the bug is still present and turns red when it is fixed, prompting removal of the marker. Other components rendering pickers inside @for/@if blocks should be audited for the same shape.

[cestercian]

Taking this — will give each @for date picker a unique id and bind correctly.