CB-578 stage A: document exhaustedPattern as a deferred reload key

The patterns are compiled once in Bridged.main from the startup config
snapshot, so adding one to a profile does nothing until a restart. Neither
the per-key docs nor the reload-class table said so.

bridged/bridged.example.yaml

@@ -144,6 +144,8 @@ herdrSocket: ~/.config/herdr/herdr.sock
 #                      omit and this profile's completion fallback behaves exactly as before.
 #                      Every backend words its refusal differently, so this is config, never a
 #                      vendor string baked into bridged itself.
+#                      DEFERRED: the patterns are compiled once at startup, so adding one to a
+#                      profile does nothing until the daemon restarts.
 #   env              → extra environment for this profile's workers, as a literal key/value map
 #                      (CB-511). Use it to give workers a toolchain.
 #
@@ -259,7 +261,8 @@ placement: weighted
 #               until you restart: `lifecycle:`, `leadHeartbeat:`, `guard:`, `worktreeRoot:`,
 #               `spawnReadyTimeoutMs` / `spawnReadyPollMs`, ADDING or REMOVING a profile (a new
 #               backend needs its own launcher, and launchers are built once), AND an existing
-#               profile's launch settings — model, baseUrl, argv, env, configDir, mcpUrl, tabLabel.
+#               profile's launch settings — model, baseUrl, argv, env, configDir, mcpUrl, tabLabel,
+#               exhaustedPattern (the patterns are compiled once at startup).
 #               The launcher takes a copy of `profiles:` at startup and resolves every spawn out of
 #               that copy, so those never reach a launch until you restart. The reload logs them by
 #               name rather than pretending they applied.