Dal_node: Add Backfill case for elements in the attestable slots stream

What

Parent MR: !19721 (merged)

Introduce a new variant on the attestable slots watcher stream - Backfill { backfill_payload } where:

• slot_ids : slot_id list - historical attestable slots relevant to the subscriber,
• no_shards_attestation_levels : int32 list - attestation levels in the window where the subscriber has no assigned shards.

This event is sent once, immediately upon subscription, before real-time events (so it could, for instance, be consumed synchronously and then an asynchronous consumer can be started). It allows the consumer to warm its cache deterministically.

The backfill window was chosen to include the last attestation_lag levels with respect to the last_finalized_level obtained from the Node_context.

Why

Because the DAL monitoring RPC (/profiles/<pkh>/monitor/attestable_slots) is, by design, a push stream of future events only. When a client (e.g., the baker) subscribes, it has no way to learn attestable events that already happened before the subscription point unless the DAL node explicitly provides them.

This is a practical problem for the baker’s DAL path, as the workflow (from !19528 (closed)) would be:

• At the beginning of a level, the baker queries “attestable slots” for that level's attestation.

• Without historical context, a cold-start baker will frequently see an empty cache and would need to fall back to the static RPC or simply miss attestations, introducing either latency or unavailability.

How

Manually testing the MR

Same scenario: run a ghostnet L1 and DAL node, and then curl the monitoring RPC to get:

{
  "kind": "backfill",
  "backfill_payload": {
    "slot_ids": [
      {
        "slot_level": 15923513,
        "slot_index": 8
      },
      {
        "slot_level": 15923512,
        "slot_index": 8
      },
      {
        "slot_level": 15923511,
        "slot_index": 8
      },
      {
        "slot_level": 15923510,
        "slot_index": 8
      },
      {
        "slot_level": 15923509,
        "slot_index": 8
      },
      {
        "slot_level": 15923508,
        "slot_index": 8
      },
      {
        "slot_level": 15923507,
        "slot_index": 8
      },
      {
        "slot_level": 15923506,
        "slot_index": 8
      }
    ],
    "no_shards_attestation_levels": []
  }
}
{
  "kind": "attestable_slot",
  "slot_id": {
     "slot_level": 15923514,
     "slot_index": 8
  }
}
{
  "kind": "attestable_slot",
  "slot_id": {
    "slot_level": 15923515,
    "slot_index": 8
  }
}
...

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR