fix(knowledge): stop capping the unpaged knowledge-base list - #6771

Summary

• Staging's integration test failed on the first run after fix(knowledge): list knowledge bases on the same authority that creates them #6770 deployed: GET /api/knowledge returned 500 with Knowledge base list exceeds the 10000 row limit. The same test had passed 28 consecutive runs over the prior two days against the same data — the delta was the code, not the volume.
• fix(knowledge): list knowledge bases on the same authority that creates them #6770 routed the internal list through the workspace read, which carried a 10,000-row cap. Soft-delete cleanup reclaims archived knowledge bases only past a retention window, and not at all where none is configured, so a workspace that archives faster than that window crosses any fixed count on its own.
• The cap could never have worked as a guard. Its throw was gated on limit === undefined, so it fired only for callers that had not asked for a page — precisely the callers with no cursor to retry with and no way to ask for less. A paged caller never reached it. It also read one row past the cap before throwing, so it refused to serve rows it had already materialized; most of the memory cost was already paid.
• Removed. An unpaged read is unbounded, matching the sibling internal lists (listTables, workspace files, neither capped). Paged callers keep their page and their nextCursorKeys. This also clears the same latent 500 in three other unpaged callers — the archived list use case, the catalog read, and the VFS name lookup — rather than only the surface that happened to fail.

Two more of the same shape, found while auditing for others:

• attachConnectorTypes threw a bare Error above its own row cap, on those same unpaged callers. Archiving a knowledge base archives its connectors, so the growth curve that broke staging could not reach it — but it is the identical construct, and the sibling latestJobsForTables has no equivalent.
• The VFS path lookup read every knowledge base whose name merely contained the term and exact-matched in JS, so a single-row lookup scaled with the workspace. It now queries the exact name and reads two rows, mirroring findActiveTablesByExactName.

Regression test reproduces the incident: it fails with the cap restored, passes without.

Type of Change

• Bug fix

Testing

Tested manually. Full apps/sim suite, type-check, lint, and all 29 audits pass.

Two things worth separate follow-up, neither in this PR:

• The integration test's teardown leaves archived knowledge bases behind, which is how that workspace reached five figures.
• sync-engine.ts accumulates every synced document's extracted text into one array with a page-count bound but no byte cap. That is where a bound would actually earn its keep.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)