CB-593: record which inherited credentials a member may keep

CB-592 blocks one credential name. The pane's login shell exports about
thirty. This records the decision for the two that matter most -
AI_GATEWAY_TOKEN and CONTEXT7_TOKEN both stay, with the reason - so a
deliberate choice never again looks like an oversight.

Also corrects the nudge-budget backfill note: CB-598 moved the budget to
per pending item today, so 'per source' was already out of date.

11-Features.md

@@ -1470,6 +1470,35 @@ callers were ever affected.
 
 ---
 
+## Which inherited credentials a member may keep
+
+**What.** A member's pane runs a login shell, which re-sources the operator's secret store and
+exports about thirty names. Exactly one of them is blocked: `GITEA_ACCESS_TOKEN`, see *Members cannot
+use the operator's admin forge token* above. This entry records the **decision** about the two that
+matter most among the rest, so that "we chose to allow it" never again looks the same as "we never
+noticed".
+
+| Credential | A member may hold it | Why |
+|---|---|---|
+| `AI_GATEWAY_TOKEN` | **yes** | It is the key a member is *meant* to use. Paid-backend members reach their model through `llm.ltms.dev`, and that token is the single front-door key. Blocking it would stop those members working at all. |
+| `CONTEXT7_TOKEN` | **yes** | It backs the `context7` documentation MCP, a read-only docs lookup that members are meant to have. The worst case is documentation reads on the operator's quota. |
+| `GITEA_ACCESS_TOKEN` | **no** | Admin scope on the forge. Blocked — see the entry above. Members push with the repo-scoped `WORKER_GITEA_TOKEN` instead. |
+
+**On.** Nothing to turn on. The two allowed tokens flow through by default; the blocked one is
+overwritten at every launch.
+
+**Why this is written down at all.** `BRIDGED_MEMBER` already exists, so splitting either of these
+per-role is now a one-line guard in the secret store. The option is cheap and available — which is
+exactly why the decision has to be explicit rather than implied by nobody having done it. The
+original leak (CB-592) was found by accident. The same accident should not have to happen twice.
+
+**Gotcha.** This decision covers **two names out of about thirty**. The rest have not been reviewed
+one by one; `CB-596` tracks enumerating them, and it needs the operator because the probe that would
+list them is refused by the command classifier. So read this table as *"these two were decided"*, not
+as *"everything else was checked and cleared"*.
+
+---
+
 ## Backfill status
 
 This page was started after the fact, so it is **not yet complete**. Entries above are written from
@@ -1491,5 +1520,8 @@ earns an entry:
   CB-594); the Linux unit has not been checked for the same login-shell secret defect, and the
   gateways it targets are CB-308 work
 - multi-profile routing and `kind:` adapter selection (CB-305, CB-401/402)
-- the reply push loop and its nudge budget (CB-307 step 2, CB-590) — note the budget is now **per
-  source**, a reply budget and a ticket budget, not one shared counter
+- the reply push loop and its nudge budget (CB-307 step 2, CB-590, CB-598) — the budget is now
+  tracked **per pending item**, not per lead and not per source. A newly-arrived item keeps its
+  source eligible even when an older, still-undrained item has used up its own budget. The practical
+  consequence to write up: the cap bounds nudges *about one item*, so a lead with a steady arrival of
+  new work keeps being nudged — which is correct, but is not what the knob's name suggests