Juju/ops only reacts to public Pebble custom notices, breaking custom notices in rocks that run workloads as `_daemon_`

Juju (through ops) only emits `pebble-custom-notice` events for **public** Pebble notices — i.e. notices recorded by the `root` user. In rocks, the recommended practice is to run workloads as the unprivileged `_daemon_` user. Custom notices emitted by a non-root user are scoped to that user's UID and are not public, so Juju never emits an event for them and the charm never wakes up.

## Current behavior

- A workload running as `_daemon_` (non-root) records a custom notice via `pebble notify`.
- Because the notice is emitted by a non-root UID, Pebble binds the notice to that user and it is **not** public.
- Juju/ops only surfaces public notices, so no `pebble-custom-notice` event is emitted.
- The charm never observes the notice and does not react.

## Expected behavior

Charms should be able to react to custom notices emitted by workloads regardless of whether the workload runs as `root` or as the unprivileged `_daemon_` user — the recommended way to run workloads in rocks.

## Impact

This makes custom notices effectively unusable as an event mechanism for any rock that follows the best practice of running its workload as `_daemon_`. Charm authors are forced to either:

- run the workload as `root` (against rock best practices), or
- abandon custom notices as a signaling mechanism.

## Environment

- Component: Juju / ops (Pebble custom notice handling)
- Workload user: `_daemon_` (non-root)
- Notice visibility: user-scoped (not public)