fix(intent): the slot picker is an additional page too, plus two repairs the #6624 merge left behind

[delchev]

Follow-up to #6624 (merged), which made a calendar view an additional page. This closes the same hole for view: slots — and repairs two things the merge sequence left behind.

1. The slot picker is an additional page too

view: slots was left replacing the layout, on the argument that a picker is an authoring surface rather than a second way to browse. That does not survive contact with a booking document: the picker is how a booking is created, the document page is how it is worked with afterwards, and an author needs both — exactly the choice #6547 was about.

So the picker gets the calendar's treatment: EdmIntentGenerator emits slotsView instead of layoutType: MANAGE_SLOTS, uiSlotsModels keys on it, and slots.js stops emitting the shared manage form — the layout owns the editor, so slot-click on a document master now lands on the document create page prefilled with the chosen datetime. The picker owns /<Entity>, the layout browses at /<Entity>/list, and the two carry a Slots⇄List switch. MANAGE_SLOTS is gone from every consumer; like MANAGE_CALENDAR it was intent-only and never offered by the entity editor, so nothing hand-authored carries it.

Nothing about a view: replaces a layout any more.

2. A view no longer double-registers its perspective

A defect #6624 introduced, which extending the rule made obvious: navigation.js's PERSPECTIVE_COLLECTIONS listed uiCalendarModels / uiSlotsModels alongside the layout collections. Once a view entity keeps its layout it is a member of both, so its perspective was generated twice — the same rename path written twice and a duplicate application-perspectives contribution. Harmless on disk (identical content overwriting itself), but wrong. Both view collections are dropped from that list; a view entity is always in exactly one layout collection.

3. The Java generation port had drifted out of parity — with no test to notice

#6628 ported generateUtils.js to Java (ModelGenerator) roughly an hour after #6624 merged, and the port was written against the pre-#6624 logic: uiCalendarModels / uiSlotsModels / personalCalendarModels / personalListModels still keyed on MANAGE_CALENDAR / MANAGE_SLOTS, which EdmIntentGenerator no longer emits.

Nothing is broken on master today — per GENERATION_UTILS_JAVA_PLAN.md both paths are live and no consumer is switched, and the JS path is what executes. But the moment PR 2 of that plan flips consumers, calendar and slots pages would silently stop being generated: an empty partition produces no files and no error.

GenerationParityIT could not catch it, because no parity fixture declares a view — every existing fixture matches on both pipelines whatever these four partitions do. Fixed here:

• ModelGenerator keys on calendarView / slotsView, and personalListModels no longer excludes calendar roots (matching the JS).
• A new views.model fixture — one calendar entity, one slot-picker entity, both keeping their MANAGE layout — registered as a parity case. Verified it is a real guard: with the ModelGenerator fix reverted the case fails on the calendar/slots page files; with it, both pipelines agree.

Verification

• EdmIntentGeneratorTest gains documentMasterWithASlotsViewKeepsTheDocumentLayoutAndAddsThePicker; unit suite green.
• IntentEmissionCoverageIT fixture gains a slots document (Visit): the /Visit picker landing route, /Visit/list, /Visit/create resolving to the document editor, and both toggles.
• GenerationParityIT green with the new fixture.
• Live: generated + published on a local instance (0 problems). The picker paints the 3-day grid honouring open/close/step; a free slot opens /Visit/create?StartsAt=… on the document editor; the saved record's edit page carries Visit Items + Add, the totals footer and Print — exactly what a slots entity used to lose; /Visit/list shows the document list with a Slots toggle. No console errors.