Stop dropping Context collections from the agent catalog

[AshishKumar4]

What does this change?

With hundreds of skills the agent saw a truncated Context Library, and collections went missing from it. Collections are how the agent finds anything at all; individual skills it can enumerate through the session's list()/search().

The returned catalog was always being bounded to a low value of 25, and at both, before returning the values in RPC and an outer bound, which made most of the skills and collections be truncated.
This PR fixes that by increasing the outer bound threshold, and separately bounding the skills catalog to a value of 150.
This PR also simplifies the getAgentCatalog API by removing the request field.
Also, normalizeAgentCatalog clamps from the tail and sorts the survivors, so the gatekeeper's order decides what lives

Why is this obviously correct and trivially verifiable?

The behavioural change is one moved .toSorted() and one reordered concatenation. The catalog policy moved into buildContextCatalog(), so it reads as a single pure function instead of being spread through a Durable Object method.

Checklist

Checking every item does not guarantee acceptance. Maintainers determine whether
a pull request meets the contribution policy.

• This is a small, concrete change; it is not a feature, refactor, or low-value cleanup.
• I understand that maintainers decide whether the change is obviously correct and trivially verifiable.
• I have read and followed the contribution guidelines.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[AshishKumar4]

I have read the CLA Document and I hereby sign the CLA

[ask-bonk]

Confirmed: skills are internally sorted, collections are internally sorted, and they're concatenated collections-first. Since the Workshop drops from the tail, collections survive unless collection count alone exceeds 200 — the intended guarantee.

I've completed a thorough review of this PR. Here's my assessment:

Summary

The change is coherent, correct, and well-contained. It fixes the "collections dropped from the agent catalog" bug via two mechanisms:

1. normalizeAgentCatalog switches from sort-then-slice to slice-then-sort (agent-catalog.ts:43-45). This makes the gatekeeper's provider ordering the priority signal, so tail-drop discards the last-listed entries rather than the alphabetically-last ones.
2. The Context gatekeeper lists collections before skills (library-gatekeeper.ts:338), so a large skill set can no longer push collections past the cap.

Verification

• No dangling references: boundAgentCatalog/AgentCatalogRequest are fully removed with no remaining importers (checked repo-wide).
• Signature change is consistent across all three sides: both gatekeepers (scheduler.ts:272, library-gatekeeper.ts:319) drop the request param, and the overseer call site (overseer.ts:4866) drops the argument. The derived CatalogGatekeeperFacet type flows correctly with no wire-format change.
• Logging follows conventions: module-scoped createWorkshopLogger, concrete dot-separated event: "agent.catalog.truncated", and size is a real member of WorkshopObservabilityFields (observability.ts:27).
• All prior review findings resolved: no unused VENDOR_ID/obsContext imports, doc comments updated (gatekeeper.ts:716-723), security/defense rationale retained and clarified (agent-catalog.ts:19-27).
• The new test genuinely distinguishes old vs new behavior (agent-catalog.test.ts:41-56): the "keep" entry with a last-sorting title survives the cap only under slice-then-sort. The deleted boundAgentCatalog suite's id-length assertion is now covered by the extended normalizeAgentCatalog test (agent-catalog.test.ts:24).
• PR body matches the code as provided to me (25→200, symbols removed) — the stale-metadata note in earlier bot comments referred to an intermediate commit.

The one non-blocking design tradeoff (if skills alone reach 200, collections could still be dropped) is genuinely mitigated by collections-first ordering: collections survive unless the collection count itself exceeds 200, a much stronger guarantee than before.

No new actionable code defects found.

LGTM!

github run

[ask-bonk]

github run

[ask-bonk]

@AshishKumar4 Bonk workflow failed. Check the logs for details.

View workflow run · To retry, trigger Bonk again.

[ask-bonk]

github run

[ask-bonk]

github run

[ask-bonk]

github run

[AshishKumar4]

bonk break glass