docs: Add a fix for command not found: nix on macOS (#7951)

docs/build/nix_troubleshooting.md

@@ -3,6 +3,78 @@
 Common issues encountered when using the [Nix development shell](./nix.md), and
 how to resolve them.
 
+## `command not found: nix` after a macOS update
+
+If a shell suddenly can't find `nix` at all:
+
+```
+$ nix develop
+zsh: command not found: nix
+```
+
+then Nix is almost certainly still installed — only the shell hook that puts it
+on your `PATH` is gone. Confirm that first:
+
+```bash
+ls -l /nix/var/nix/profiles/default/bin/nix
+```
+
+If that exists, the installation is fine and this is purely a `PATH` problem.
+
+### Why it happens
+
+The installer does not touch your dotfiles. Instead it sources a setup script
+from the Nix store by editing **system-wide** rc files:
+
+| Shell | File the installer edits              |
+| ----- | ------------------------------------- |
+| bash  | `/etc/bashrc`, `/etc/bash.bashrc`     |
+| zsh   | `/etc/zshrc`                          |
+| fish  | `$__fish_sysconf_dir/conf.d/nix.fish` |
+
+macOS manages `/etc/zshrc`, so an OS update can replace it with the vendor copy
+and silently drop the Nix block. `/etc/bashrc` and the fish file usually survive,
+which is why the breakage often shows up in zsh only. You can verify this by
+diffing against the backup the installer left behind:
+
+```bash
+diff /etc/zshrc /etc/zshrc.backup-before-nix
+```
+
+If they are identical, the Nix snippet was wiped. This is upstream issue
+[NixOS/nix#3616](https://github.com/NixOS/nix/issues/3616).
+
+### Fix
+
+To unblock the current shell:
+
+```bash
+. /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh
+```
+
+For a permanent fix, add the snippet to your **user** rc file rather than
+restoring `/etc/zshrc` — user dotfiles are not clobbered by OS updates:
+
+```bash
+cat >>~/.zshrc <<'EOF'
+
+# Nix
+if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
+  . '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
+fi
+# End Nix
+EOF
+```
+
+The scripts guard against double-sourcing via `__ETC_PROFILE_NIX_SOURCED`, so
+this is safe even if a system-wide hook is later restored.
+
+> [!NOTE]
+> `/etc/zshrc` and `~/.zshrc` are only read by **interactive** zsh. If the
+> snippet is present but `zsh -c '…'`, a script, or an IDE terminal still can't
+> find `nix`, that shell is non-interactive — put the snippet in `~/.zshenv`
+> instead.
+
 ## Git worktrees
 
 If `nix develop` fails with an error like: