Cardano Updates

<!-- Describe your change here -->

After rotation, we now reset the number of events to 1 (not 0),
because the checkpoint event is sourced on restart. This avoids
a mismatch between the rotation check on startup and during normal
operation.
That discrepancy was the cause of inconsistent rotation log ids after
restarts.

Also, we changed the rotation condition to use (>) instead of (>=),
preventing a follow up rotation on start up when the configured
threshold is 1
(since checkpointing would immediately trigger a new rotation).

Lastly, a checkpoint event id now matches the last persisted event id
from its preceding rotated log file, preserving sequential order of
event ids across logs.

This also makes it easier to identify which rotated log file was used to
compute the checkpoint,
as its event id matches the file name suffix.

---

<!-- Consider each and tick it off one way or the other -->
* [X] CHANGELOG updated or not needed
* [x] Documentation updated or not needed
* [x] Haddocks updated or not needed
* [x] No new TODOs introduced or explained herafter

After rotation, we now reset the number of events to 1 (not 0),
because the checkpoint event is sourced on restart. This avoids
a mismatch between the rotation check on startup and during normal operation.

To support this, we changed the rotation condition to use (>) instead of (>=),
preventing an infinite rotation loop when the configured threshold is 1
(since checkpointing would otherwise immediately trigger a new rotation).

Lastly, the checkpoint event id now matches the last persisted event id
from the last rotated log file, preserving the sequential order
of event ids across logs.

This also makes it easier to identify the last rotated log file from a checkpoint,
as the checkpoint event id matches the log file name suffix.

<!-- Describe your change here -->

Closes #1937 

Add workaround for known etcd cluster join issue by setting the
ETCD_INITIAL_CLUSTER_STATE environment variable to "existing" (default
is "new").

Notes:
- This workaround is effective as long as the peer maintains its network
configuration; which determines its etcd member ID and keeps it stable
upon restarts, even on newly created persistence.
- When set to "existing", the etcd member attempts to join an already
bootstrapped cluster.
- If the value is incorrect, etcd will attempt to start but fail safely.

---

<!-- Consider each and tick it off one way or the other -->
* [X] CHANGELOG updated or not needed
* [X] Documentation updated or not needed
* [X] Haddocks updated or not needed
* [X] No new TODOs introduced or explained herafter

---------

Signed-off-by: Sasha Bogicevic <[email protected]>

Signed-off-by: Sasha Bogicevic <[email protected]>

* this starts grafana and prometheus from docker-compose

* from docker-compose demo containers
* from nix process-compose demo commands