refactor(rest): retire the public lookup route's picker.sort read (#7485) - #7509

Executes the maintainer's four-lens ruling recorded on #7485 (02:55Z): Option 2 — retire the read.

Closes #7485

The gap this closes

GET /forms/:slug/lookup/:field composed its findData query with

sort: picker.sort ?? [{ field: displayFields[0], order: 'asc' }],

— a fifth read of the publicPicker block whose declaration (#7467, landed by PR #7487) enumerated four keys: displayFields, maxResults, filter, object. sort was in neither the schema nor the enumeration, which left it in exactly the state ADR-0049 calls the mirror-gap, one key wide: enforced by the route, declarable nowhere. The block is strict (ADR-0089 D3a), so a form authoring publicPicker.sort is an unrecognized_keys parse error — no form written since #7467 has ever reached that read.

The ruling closes the gap by removal rather than declaration: sort has zero measured pull, and declaring it would mean permanently maintaining one more public knob on an unauthenticated search surface. Ordering is now fixed — first display field, ascending — and is the only behavior. If real demand appears, the declare fork re-runs then; it stays cheap.

Changes

Both sides of "ignored, not an error" are pinned, per the card:

• the schema refuses a new form authoring publicPicker.sort through the real saveMetaItem write path — no row is written (with the byte-identical form minus sort saving as the control, so sort is provably the sole cause);
• a pre-publicPicker is enforced by the REST lookup route but declared nowhere in packages/spec — no saved form can ever enable it #7467 stored row still carrying sort — rows persisted before the block was declared never went through ViewMetadataSchema, so one can carry a key the schema refuses today — is read past, answered 200, ordering unchanged, and the stored { field: 'email', order: 'desc' } reaches findData nowhere;
• the fixed sort tracks displayFields[0], including the no-displayFields default (it is "first display field, ascending", not a frozen constant).

That stored-row half is why the route pin lives in packages/rest rather than the spec suite: the route must neither honor the stale key nor choke on it — a 500 on an anonymous surface would be a regression the removal itself caused.

Impact

None for any form that parses today — the read was unreachable through the authoring path. The declared four publicPicker keys are untouched.

Gates

Reverse verification

Predicted in writing before running; all three landed exactly as predicted.

Scope boundaries observed

Sibling finding #7486 (the target fallback reading only referenceTo / target / options.objectName) is not touched. No content/docs/releases/, no docs/adr/**.

Finding noted, not fixed here

Through ViewMetadataSchema's union, a form that fails the ViewItem branch on a bad publicPicker subkey reports the container branch's diagnostic instead — the author sees Unrecognized key(s) on this view container: viewKind, config rather than a message naming sort. Pre-existing, unrelated to this change (the direct FormViewSchema door names the key correctly), and recorded on the issue rather than fixed as a rider.

Generated by Claude Code