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

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 #547, just a case that fix does not reach
- moving `` before `` 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:

```html

...

```

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.

Start with floating-rate-form.component.ts and reproduce the added-row failure at /products/floating-rates/create. Read e2e/date-picker-revisit.spec.ts and its test.fail() assertions to understand the expected binding and unique IDs. Done means each added row opens and edits its own picker, the assertions pass, and the test.fail() marker is removed; audit other @for/@if picker instances as described.

Written by the indexing model from the issue text.