Support per-rule actions and SECCOMP_FILTER_FLAG_NEW_LISTENER loading

[lu-zero]

Summary

Make SeccompAction::UserNotif (added in #95) usable in hybrid filters,
where different syscalls take different actions in one filter. SeccompFilter
applies a single match_action to every rule today; this adds per-rule actions
and a loader for SECCOMP_FILTER_FLAG_NEW_LISTENER.

Motivated by fakeroost#7,
which routes stat through a USER_NOTIF pool while keeping writes on TRACE —
previously requiring hand-rolled BPF. Reference port:
fakeroost#8.

Relationship to #75

#75 (colinmarc, stalled since Apr 2025) adds a Notify variant + a loader but
not per-rule actions — it can't express "syscall A → Notify, syscall B → Trace"
in one filter, which is the gap this PR fills. #95 already merged UserNotif
unconditionally, superseding #75's feature-gated Notify. Our loader
(apply_filter_with_listener) overlaps #75's apply_filter_with_notify_fd; happy
to adopt that name if preferred.

Changes

• SeccompRule gains action: Option<SeccompAction>; None falls back to the
  filter's match_action (existing usage unchanged). New constructors
  new_with_action (conditions + action) and always (unconditional). First
  matching rule wins; append_syscall_chain emits the rule's own RET.
• validate() relaxed: a condition-less rule is valid iff it carries an action.
• apply_filter_with_listener() -> Result<OwnedFd> installs with NEW_LISTENER
  (Linux 5.0+) and returns the listener fd. Separate from
  apply_filter_with_flags (rc contract differs: positive rc = fd, not TSYNC).
• new_with_action(vec![], ..) now returns Err(EmptyRule) — previously it
  silently behaved like always.

SeccompAction::UserNotif is intentionally unit: the kernel ignores the
return-data bits for SECCOMP_RET_USER_NOTIF, so a u32 would be a tag it
discards (unlike Errno/Trace). See docs/design-per-rule-actions.md.

Testing

New unit + integration tests for the above; 36 tests / 5 suites pass,
clippy -D warnings clean, fmt clean. fakeroost's integration suite passes
on this branch (#8).

Open questions (none block this draft)

1. IdenticalActions is over-strict when every rule overrides.
2. JSON frontend has no per-rule action field yet (non-breaking).
3. No notification consumer API; low-level bindings are landing in libc
   (#5224); a high-level
   supervisor API would be a separate crate.

Draft to gather feedback — especially on reconciling with #75 — before
finalizing.

[rbradford]

I like the idea of being able to specify specific actions for different rules but I think this commit is overloaded with too many disparate changes. Please split the work.

[rbradford]

Please make the CI pass.

[lu-zero]

It should be fine now