Make snap broker service restarts wait for broker readiness

The authd broker snaps currently use `daemon: dbus`, so snapd generates systemd services with `Type=dbus`. Systemd considers these services started as soon as they claim their well-known D-Bus name.

#1832 deliberately moves the name claim before fallible broker initialization. This lets D-Bus activation fail quickly instead of waiting for the 25-second activation timeout. However, it also means systemd considers the service ready before configuration validation and broker initialization have completed.

As a result, this command can finish before the broker is actually ready or has failed:

```shell sudo systemctl restart -v snap.authd-msentraid.authd-msentraid.service ```

On Ubuntu 26.04 and later, `systemctl -v` displays unit logs while the operation is pending. Because the `Type=dbus` start operation completes at the early name claim, it can stop displaying logs before the useful initialization result. The restart can also report success even if the broker exits with an initialization error immediately afterward.

The broker already sends `READY=1` after `dbusservice.New` completes, but `Type=dbus` does not use that notification to determine readiness.

## Proposed change

Use `daemon: notify` for the broker snaps while retaining `activates-on` for D-Bus activation.

Add the `daemon-notify` plug and obtain auto-connection for it before making the change. Without auto-connection, the broker cannot send `READY=1` and service startup would fail or time out.

With `Type=notify`:

- systemd keeps the start job pending until broker initialization completes and `READY=1` is sent; - `systemctl restart -v` displays logs until the broker is ready or exits with an initialization error; - `systemctl restart` returns a failure for invalid broker configuration; - the early D-Bus name claim and gated method calls from #1832 can remain in place, preserving fast D-Bus activation failures.

Moving away from `Type=dbus` removes systemd's supervision of the well-known D-Bus name. The broker must therefore detect loss of its D-Bus connection or name and exit. Otherwise, systemd could report an active service whose D-Bus interface is no longer reachable.

Locate the broker snap service definitions and read the startup path around dbusservice.New and its existing READY=1 notification. Update the service integration so startup waits for readiness and verify the daemon-notify connection is available automatically. Done means restarts report initialization failures, remain pending until readiness, and the broker exits when its D-Bus connection or name is lost.

Written by the indexing model from the issue text.