[FEATURE] pup monitors diff — preview changes against live state before update

[jholm117]

Is your feature request related to a problem?

pup monitors update <id> <file.json> applies a monitor definition blind — there's no way to preview what will actually change versus the live monitor before committing. For production monitors (alert thresholds, evaluation windows, notification routing), that's risky: a typo or an unintended field overwrite can page on-call or silence a real alert, and you only find out after the write.

There's a get and an update, but nothing in between to answer "what will this update actually change?"

Describe the solution you'd like

pup monitors diff <id> <file.json> — fetch the live monitor, normalize it, and print a field-level diff against the candidate JSON you'd pass to update:

• Ignore server-managed/read-only fields by default (id, created, created_at, modified, deleted, overall_state, overall_state_modified, creator, org_id, matching_downtimes) so the diff reflects only intended changes.
• Print "no changes" when in sync.
• Don't signal the presence of a diff via exit code — reserve non-zero for actual errors (file not found, invalid JSON, fetch failure), consistent with the rest of pup.
• Optional --ignore <field> / --only <field> to scope the comparison.

Describe alternatives you've considered

• Manual get | jq | diff: pup monitors get <id> --no-agent | jq '...strip read-only...' and diff against a normalized candidate. Works, but verbose and easy to get wrong (which fields are server-managed isn't obvious).
• A local shell-function wrapper that intercepts pup monitors diff and does the get/normalize/diff. Fine as a personal stopgap, but every user reinvents it and the read-only field list drifts from what pup itself knows.

A native subcommand is the right home for this since pup already owns both the fetch and the schema.

Additional context

• The diff should compare the resource body, not the agent-mode {status, data, metadata} envelope.
• The same get → normalize → diff pattern would be valuable for any resource that has both get and update — dashboards, downtime, slos, monitors. A shared diff verb across those (or a generic pup <resource> diff) would be ideal, with monitors as a natural first target.
• Conceptually this is a terraform plan-style dry run for imperative monitor edits — the safety gap between get and update.

Proposed command syntax (if applicable)

# Diff a candidate definition against the live monitor
pup monitors diff <monitor-id> <candidate.json>

# Scope the comparison
pup monitors diff <monitor-id> <candidate.json> --only options.thresholds
pup monitors diff <monitor-id> <candidate.json> --ignore message