VS Code's terminal audio/accessibility signals are intrusive, confusing, and absurdly difficult to disable

### Type
UX / Accessibility / Terminal feedback

### Environment
- macOS
- VS Code Integrated Terminal
- zsh

### Problem

I just burned an unreasonable amount of time trying to stop VS Code from making a fucking noise every single time I run a command in the integrated terminal.

Ordinary commands like:

```bash
git status
git remote -v
pwd
echo test
```

all trigger an audible sound after they finish.
Same shell, same directory, same commands in Warp and iTerm2 → complete silence.
So this is 100% VS Code.

What makes this especially infuriating is how scattered, poorly named, and deliberately hard to find the controls are.

I tried the obvious terminal settings:

```
"terminal.integrated.enableVisualBell": false
```

Disabled shell integration:

```
"terminal.integrated.shellIntegration.enabled": false
```

Turned off the terminal bell accessibility signal:

```
"accessibility.signals.terminalBell": {
"sound": "off",
"announcement": "off"
}
```

None of that stopped the noise.

The actual culprit was yet another pair of accessibility signals for command completion:

```
"accessibility.signals.terminalCommandSucceeded": {
"sound": "off",
"announcement": "off"
},

"accessibility.signals.terminalCommandFailed": {
"sound": "off",
"announcement": "off"
}
```

And the nuclear option that finally shut it up:

```
"accessibility.signalOptions.volume": 0
```

This is unacceptable UX.

I get why accessibility signals exist.
What I do **not** accept is that a developer has to reverse-engineer half a dozen different systems (terminal bell, visual bell, shell integration, accessibility signals, command-succeeded signals, command-failed signals, global accessibility volume) just to answer a dead-simple question:

**Why the hell is VS Code beeping at me after every command, and how do I turn it off?**

This should not require debugging VS Code itself.

The terminology is a mess. We now have:

- `terminal.integrated.enableVisualBell`
- `accessibility.signals.terminalBell`
- `accessibility.signals.terminalCommandSucceeded`
- `accessibility.signals.terminalCommandFailed`
- `accessibility.signalOptions.volume`
- `editor.accessibilitySupport`

From a user’s perspective these are multiple independent layers that all produce the exact same result: **VS Code makes an unwanted sound**.
Discoverability is terrible. Searching for “terminal sound”, “terminal audio”, “terminal beep”, “command sound”, etc. does not surface everything cleanly.

### Why this matters

This is not a minor cosmetic annoyance.
I wasted real time:
- Checking my shell config and zsh hooks
- Disabling VS Code shell integration
- Testing the same commands in other terminals
- Reloading VS Code repeatedly
- Hunting through unrelated-looking accessibility settings

All because VS Code decided that ordinary terminal commands should play an audio cue by default.

A feature that is supposed to help accessibility should not create this much friction for everyone else.
If you’re going to play sounds, there needs to be **one** obvious, discoverable switch.

### Suggested changes

1. Do **not** enable terminal command success/failure sounds by default. Make them opt-in.
2. Add a single, clear setting such as:
```
Terminal: Disable All Sounds
```
or
```
"terminal.integrated.audioFeedback": "off"
```
3. Keep all terminal-related audio controls under the Terminal settings section instead of scattering them across Accessibility.
4. When a terminal sound plays, give some indication of which signal produced it.
5. Searching for common terms (“terminal sound”, “terminal audio”, “terminal beep”, “command sound”, etc.) should surface every relevant setting.
6. Stop forcing users to understand the internal distinction between “terminal bell”, “accessibility signal”, “command success signal”, and shell integration just to silence an unwanted noise.

### Expected behavior

If I have not explicitly asked VS Code to play sounds when terminal commands succeed or fail, it should stay silent.
And if it is making noise, there should be one obvious place to turn it off.

Right now the experience is needlessly intrusive, confusing, and a complete waste of users’ time — the kind of over-engineered, poorly discoverable default behavior that feels straight out of the Windows playbook.

Please fix the defaults and the discoverability. This should not be this hard.