Search-first Schema picker and admin tables for large namespaces

[alistair3149]

Cursor pagination on the list endpoints (follow-up to #1062) makes full enumeration cost O(readable rows), but two frontend surfaces still assume the Schema namespace is small:

• The relation-property Schema picker (SchemaPicker.vue via SchemaStore.getAllSchemaSummaries) loads every Schema summary client-side and filters in the browser. At thousands of Schemas that is dozens to hundreds of sequential page requests and a multi-thousand-row client list per picker mount.
• The admin tables (Special:Schemas, Special:Layouts, Special:Mappings) page 50-at-a-time with next/prev only; walking a 12k-row listing 50 rows per click is not a usable way to find anything.

Both should become search-first: type-ahead against the server-side GET /neowiki/v0/schema-names/{search} prefix lookup (already read-gated per #1046) rather than client-side filtering of a full enumeration, with the paged listing kept as the browse fallback. The admin tables may additionally want a search box backed by the same lookup; Layouts/Mappings need an equivalent name lookup only if their namespaces ever grow beyond trivial size (Mappings stay one-per-ontology by design).

Not urgent while deployments hold tens of Schemas — the picker caches the enumeration per page view and the tables are fine at that size. It becomes the limiting factor exactly when the cursor work pays off, so it should land before any deployment that expects large Schema namespaces.

_{AI-authored — Claude Code, Fable 5 (xhigh); follow-up split out of #1062 as part of its user-approved fix plan, filed by direction of @alistair3149; not human-reviewed; scale claims grounded in the PR #1131 implementation (picker enumeration and table paging read from the current code), otherwise unverified.}

[JeroenDeDauw]

walking a 12k-row

That's not realistic for any of them. On a typical wiki all of those will stay below 50. Reaching 1000 requires doing some real weird stuff and is not something we have to nicely support, esp not for MVP, and esp not if it trades off anything from the common use cases.

I recently touched the schema picker somewhere. Don't remember where. But I do remember the UX was bad, as the user had to know the names of the schemas to find anything and could not view the list of existing ones. So I loaded all schemas after considering the performance and scalability implications and concluding the "load all" approach works well enough.

[alistair3149]

That's not realistic for any of them. On a typical wiki all of those will stay below 50.

I agree that 12k might not be realistic, it is over-estimated.
Do we have estimates of how many schemas, layouts, and mapping that we should support?
I had the assumption that the schemas might reach several hundreds in the ECHOLOT use case.

the UX was bad, as the user had to know the names of the schemas to find anything and could not view the list of existing ones

There are no conflict with the approach here. A sensible initial state for the suggestion is nice-to-have.
Though for now, this issue is more of a scalability concern that is not important for MVP atm.

[JeroenDeDauw]

Wikidata has 451 Schemas which is an extreme case and upper bound. Fable estimates 5-30 for museum collections tail cases of event-style in-wiki models going perhaps up to 150 and certainly not more than 300. That is handled well by what we currently have. We could revisit if we commonly get over 300 Schemas.