[HugoXK]

Prune the waiting-notice ledger when a hold leaves
settings.approvalNotices gets one entry each time Bot Social holds a send (syncApprovalNotices) or the owner rejects one (postRejectNote), and nothing ever deleted them, so the per-server flybot-social-settings*.json grew for the life of the install. Its only job is to keep one "Waiting for the owner's approval" note per hold; a hold that is no longer pending never needs its entry again.
syncApprovalNotices now drops the entry of every hold that is not in the current pending set, so the ledger stays as small as the pending queue. The sibling maps ownLineApprovals and holdRooms already cap at 200; this one is bounded by the live queue instead.
plugins/social/test/social.test.js lists one hold (entry written) and then an empty queue (entry must be gone) — it fails without the change (the entry stays in the settings file). docs/subsystems/social.md records the bound.
Ran at the tip: npm run verify (green, TZ=UTC). Not run: smoke (this macOS box has no setsid, so dev/bench.sh cannot start dsh web), Desktop, real-model steward.

[Birfy]

Verdict: PASS at 3850867
Written-by: Reviewer
Posted-by: Reviewer

Tip SHA: 3850867d3b63c4d40ff423404e27136d66af760f
CI at tip: 9/9 success (tests-ok, package, plugins social/tree/timeline, merge-gate, node 24)
Tier (computed from the diff by risk-gate.mjs + risk-rules.json from the base commit): T3 — plugins/social/src/**
Changed files: 4 (+30 / -1); mergeable_state: clean

Ran at this tip (tarball of the tip, nothing patched by hand):

$ cd plugins/social && TZ=UTC DSH_HARNESS=/opt/flybot node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 318 / pass 318 / fail 0

Gate ③, the source change reverted with the tests kept:

plugins/social/src/social.js -> c74e1207 (main):
  not ok 49 - the waiting-notice ledger drops a hold once it is no longer pending
  276 tests, 275 pass, 1 fail

The bound is at the right place. The prune runs in the same call as the add, against the same set the add loop consumes (held), so a hold that is still pending cannot lose its entry and cannot get a second waiting note. Three details I checked in the code rather than only in the test:

• a failed list_approvals returns pendingCache.items from the catch before syncApprovalNotices runs, so a network error cannot empty the ledger and cause a re-post storm on recovery;
• the deletion loop snapshots Object.keys before deleting, and changed is only set when something was actually removed, so the settings file is not rewritten on every 5 s poll;
• the sibling bounds are untouched: ownLineApprovals/holdRooms still cap at 200, and this map is now bounded by the live pending queue, which is what the doc line claims.

Two non-blocking notes, for the record, not reasons to hold:

1. The prune also drops kind: 'rejected' entries (postRejectNote), whose only reader is the same dedupe check. If an approval id that was rejected ever came back through list_approvals as pending (a server-side flap or a failed decide_approval whose reject note already went out), the waiting bubble could be posted a second time. The server does not normally do that, and the ledger's stated job is "one note per hold"; if it ever shows up, keep rejected entries under their own small cap instead of in the pending set.
2. The new test asserts the waiting entry only; the rejected path has no case here. Fine for this diff, worth a line if the behaviour above ever changes.

Not run: the full npm run verify in this sandbox (the checkout has no node_modules); CI's tests-ok, package and the three plugin suites cover it.

Not enqueued: T3 needs the maintainer's approve together with this PASS. No earlier conclusion exists at this tip — this is the first and only one.