Let a crash diagnosis mute that program's notifications

A crash that is understood is not a crash that stops: an upstream bug waiting on a release, a program that dumps core every time it exits. The diagnosis explains it once and the toast keeps arriving, and the only answer Omarchy had was Crash Capture, which turns off every program's notifications in order to silence one.

The watcher already resolves a name to dedupe on and announces that same name in the toast, so the mute is keyed on it: a flag file under toggles/crash-ignore/, written by the existing omarchy-toggle and read by the existing omarchy-toggle-enabled. One flag per name rather than one list, so `on` mutes, `off` un-mutes, and `ls -A` shows what is muted, with no new file format and nothing to parse. It is the executable's basename wherever one was recorded, falling back to the process name, which the kernel truncates to fifteen characters -- muting the truncated form would match nothing, forever, while looking like it worked.

The name is not always a name, though, and the mute turns it into a path. A program picks its own comm and prctl takes anything, including slashes, and the watcher falls back to comm whenever a crash carries no absolute executable. So it is stripped to its last component first: without that, `a/../bar-off` is a legal comm aimed at an unrelated Omarchy flag, letting a crashing program suppress its own notification and letting a user who accepted the offered mute hide their bar instead. Stripping does not always leave a component either -- `/` leaves an empty string, which is no kind of array subscript and no kind of toast, and `.` or `..` names a directory that omarchy-toggle would touch and report success on, leaving a mute that never matches. Both fall back to `unknown`, the word omarchy-agent-crash already uses for a name it does not have, and which mutes like any other.

The skill offers this at the end of a diagnosis and never runs it unprompted, which makes it the single change a diagnosis may make to a system it otherwise only reads. It tells the agent to use the name it was handed rather than re-derive one, since the watcher resolved that name already and the two agree for ordinary names and not for strange ones; a diagnosis started by hand from `omarchy agent crash <pid>` is given no name and gets the derivation instead. It also says to treat the name as hostile text rather than as a word -- it is whatever the crashed program's author called a file, so a single quote inside one closes the quotes around it and the rest runs as the shell -- and to check the flag arrived rather than assume it.

Co-Authored-By: Codex XHigh <noreply@openai.com>

default/agents/skills/diagnose-crash/SKILL.md

@@ -87,7 +87,60 @@ ambiguous, say so rather than assembling confidence out of guesswork.
 
 **Leave the system as you found it.** Diagnosis reads; it does not fix, tidy, or
 reconfigure. The one thing to clean up is your own: delete the core you extracted
-above, which is a copy of the crashed process's memory.
+above, which is a copy of the crashed process's memory. The single change a
+diagnosis may make is the mute below, and only when the user asks for it.
+
+## Offer to stop the notifications for this program
+
+A crash that is now understood keeps announcing itself, and understanding it
+rarely stops it happening: an upstream bug waiting on a release, a program that
+dumps core every time it exits, a driver that misbehaves on this hardware. Finish
+by offering to silence crash notifications for **that one program**:
+
+```bash
+omarchy-toggle 'crash-ignore/<program>' on
+```
+
+`<program>` is the `process:` name in the crash facts, verbatim. The watcher works
+that name out and then announces it, so what you were handed is already the exact
+string the mute is keyed on — do not re-derive it from `coredumpctl` when you were
+given it, because the two agree for ordinary names and not for strange ones.
+
+A diagnosis started by hand from `omarchy agent crash <pid>` is given no name, so
+there you do have to work it out the way the watcher does: the executable's
+basename when an absolute `Executable:` was recorded, otherwise the process name
+with everything up to the last `/` dropped, and `unknown` when that leaves
+nothing, `.` or `..`. Prefer the executable — the kernel truncates the process
+name to 15 characters and does not truncate the basename, so a mute on the
+truncated one matches nothing, forever, while looking like it worked.
+
+The name is whatever the crashed program's author chose to call a file, so handle
+it as hostile text rather than as a word. Single quotes hold a space or a `$(...)`,
+but a name containing a single quote closes them and the rest of it runs as your
+shell — escape it, or the program that just crashed chooses the command. Then
+check the flag actually arrived, which is also how you learn a name was too long
+for the filesystem to keep:
+
+```bash
+omarchy-toggle-enabled 'crash-ignore/<program>' && echo muted
+```
+
+Offer it; never run it unprompted. The user may well want to keep being told.
+
+Say how to undo it in the same breath, so it is not a one-way door: the same
+command with `off` un-mutes, and each mute is one file in
+`~/.local/state/omarchy/toggles/crash-ignore/`, which `ls -A` lists — the
+directory appears with the first mute, so before that there is nothing to list.
+
+The key is a bare name, so programs sharing one share a mute, and anything run
+through an interpreter is keyed as the interpreter. Muting `python3.13` or `node`
+silences every other Python or Node program on the machine, which is rarely what
+the user means: say so rather than quietly doing it.
+
+This silences one program. Every other crash still notifies, and the muted
+program still crashes — nothing here fixes anything, and a mute offered instead
+of a fix that was within reach is the wrong answer. If the user wants crash
+notifications off altogether, that is _Trigger > Toggle > Crash Capture_ instead.
 
 ## If it is an Omarchy bug