Expose `permission_mode` to background `monitors.json` tasks (parity with hooks)

What

Background monitors (the periodic polling tasks a plugin registers via monitors.json) do not receive permission_mode in their payload, whereas hooks (PreToolUse, UserPromptSubmit, …) already do. Please give background monitors the same field (or an equivalent way to read the session's permission posture).

Why / use case

A plugin can register a monitor that polls an external system (CI status, PR/MR state, a job queue) and wakes the agent when something completes. A natural next behavior is to automatically continue queued follow-up work once the poll detects completion — but doing that safely should depend on the user's current trust posture:

• in a permissive posture (e.g. bypassPermissions), auto-continue is what the user wants;
• in default / plan, the monitor should instead just notify and wait for confirmation.

Today the monitor has no access to permission_mode, so it's forced into all-or-nothing: always prompt (defeats the automation) or always proceed (unsafe — outward actions like pushing commits could run unattended). Reading the mode would let plugins gate autonomous actions on the user's chosen trust level.

Design question (why this needs maintainer input)

Monitors run detached from any interactive session, so "the current permission_mode" is genuinely ambiguous. Possible options:

• (a) expose the last-active session's mode;
• (b) a session-agnostic default (e.g. always default for background tasks);
• (c) let each monitor declare a mode/policy in monitors.json.

Note

Hooks already expose permission_mode in their stdin JSON, so this is really about bringing background tasks to parity.