Allow personal notification muting during local development

[morgmart]

What this does

Adds an optional personal mute for local development. Notifications behave normally unless a developer explicitly sets BUZZ_DEV_NOTIFICATIONS=0 in their uncommitted .env.local and restarts the dev server.

Why it matters

A developer can silence duplicate alerts from their checkout without changing anyone else's default or overwriting saved account choices. Production builds ignore this setting.

Behavior

• Only the exact value 0 pauses development alerts and permission requests. Unset, empty, 1, or other values keep normal behavior, subject to saved preferences and system permission.
• The host notification policy applies the pause to built-in messages and plugins. Settings explains the local override, disables the master alert control while paused, and explains how to remove the override.
• Production builds always emit pause-off, including builds run with development mode or a local mute setting. No account preference migration, native bridge change, new dependency, or launcher change is included.
• .env.example and contributor/notification documentation describe the opt-out. No personal environment file was changed.

Scope split

Dock labels, their launcher/generator/tests, and the just desktop change have been removed from this net diff. They are implemented separately in draft PR #113, stacked on the shared argument/port launcher in #109. That PR uses content-keyed icon paths for warm-build invalidation and retains #109’s inherited package-manager execution rather than the removed Bash-only path. Native Dock acceptance and Windows launcher execution remain explicitly unverified there.

Verification

Checked head: 9188d1f835718f79914892aa60f77d98f63e4b57, clean working tree.

• Mandatory pre-commit/pre-push hooks passed: formatting/lint, secret scan, TypeScript, all 1,791 Vitest tests in 173 files, design-system types and guards. Vitest wall time: 17.16s; full push gate: 20.32s on Apple Silicon macOS.
• Real Vite-config subprocess coverage exercises a truly unset setting, explicit process values, and an isolated .env.local; checks development serve and production/development-mode builds. It does not read personal environment files, start a server, or contact a relay.
• Mounted Settings + real service coverage verifies paused/normal controls, permission and delivery suppression, and unchanged saved preferences. Independent delta review found no blockers and reran those three focused tests successfully.
• Test count: two added mounted Settings cases versus base; the existing config test is extended. Five Dock-only cases from the earlier PR revision were removed with their feature. No browser cases added or removed.
• All hosted checks pass at this head: JavaScript, Rust/tool integration, Windows native notifications, Chromium/WebKit journeys, browser measurements, CI required, DCO, Semgrep, and zizmor. Required human/code-owner approval remains outstanding.

Deferred acceptance

No attended browser/native launch, responsive screenshot pass, or real OS notification/banner interaction was performed. The automated tests prove configuration, service policy, and semantic Settings behavior, not native appearance or permission dialogs. The PR remains draft pending manual acceptance.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

No blocking findings in the current notification-only diff at 9188d1f835718f79914892aa60f77d98f63e4b57, reviewed from merge-base aed15028e1a212d909ff93999b72dd118e3fc1d6 (current target main: 7028b3e5c2671d797be92014ac87be48b3ad9515). This is a review comment, not a GitHub approval.

The scoped contract is coherent: only exact BUZZ_DEV_NOTIFICATIONS=0 during development serving enables the pause; builds emit pause-off. Built-in message and trusted-plugin submissions share the same admission/delivery guards, explicit permission requests are suppressed, and the flag is separate from persisted account preferences. Settings reports the temporary override and how to remove it. Dock labels and launchers are outside this net diff.

Validation: source/control-flow review and independent configuration/UI review; existing hosted checks are all successful at this head. The config regression exercises the actual Vite config in an isolated subprocess, and mounted Settings coverage uses the real service and checks unchanged stored preferences. I did not duplicate those suites locally or launch the app. Real OS banners/permission dialogs, native appearance and attended UI acceptance remain unverified, as disclosed in the PR.