feature: emit systemd sd_notify readiness notification on startup

Feature Request: systemd sd_notify readiness notification

Summary

exporter-toolkit already supports systemd socket activation (added in #95), using go-systemd/v22/activation. It would be a natural
complement to also send a READY=1 readiness notification to systemd
once the exporter is actually listening and ready to serve requests.

Motivation

Without sd_notify support, exporters built on this toolkit cannot use
Type=notify in their systemd service units. They are limited to
Type=simple or Type=exec, where systemd considers the service
"started" as soon as the process is exec'd — before it is actually
listening on its port.

This matters in practice when:

• Other units declare After=<exporter>.service and need the exporter
  to be truly ready before they proceed.
• Operators want accurate startup ordering and timing in systemctl status / systemd-analyze.
• The exporter starts slowly (e.g. expensive collector initialisation)
  and a dependent unit races against it.

Since all exporters using this toolkit share the same ListenAndServe
path, implementing this once here would benefit the entire ecosystem
(node_exporter, blackbox_exporter, etc.) for free.

Prior art in this repo

• #95 / #225: socket activation support and the open request to
  auto-detect $LISTEN_FDS — this feature is in the same spirit of
  "be a well-behaved systemd service automatically".
• #152: open issue on signal handling for proper systemd unit operation
  — further evidence that systemd integration is a recurring concern.

Implementation notes

The relevant API is github.com/coreos/go-systemd/v22/daemon, specifically:

daemon.SdNotify(false, daemon.SdNotifyReady)

This module is already a direct dependency of exporter-toolkit
(used by the activation sub-package for socket activation), so no new
dependency would be introduced.

Expected outcome

Exporters using this toolkit would work correctly with
Type=notify in their systemd service unit:

[Service]
Type=notify
ExecStart=/usr/bin/node_exporter

Systemd would then only consider the service "active (running)" once the
exporter signals readiness, enabling reliable After= ordering for
dependent units.

Start by locating the shared ListenAndServe path and reviewing the activation package’s existing go-systemd/v22 integration. Trace when the exporter is listening and ready to serve, then verify that readiness notification behavior is covered by tests and works with a Type=notify systemd unit.