fix(intent): the slot picker is an additional page too, and the Java generation port keeps parity

[delchev]

Two commits, both follow-ups to the calendar-as-additional-page change (#6624).

1. view: slots becomes 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, slots.js stops emitting the shared manage
form (the layout owns the editor, so a slot click on a document master now lands on the DOCUMENT
create page prefilled with the chosen datetime), the picker takes over /<Entity> while 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.

It also fixes a defect the calendar commit introduced, which extending the rule to slots made obvious:
navigation.js's PERSPECTIVE_COLLECTIONS listed uiCalendarModels/uiSlotsModels alongside the
LAYOUT collections. Now that 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. The two view collections are dropped from that list; a view
entity is always in exactly one layout collection.

2. The Java generation port keeps parity on those views

A latent break in #6628. That PR ported generateUtils.js to Java about an hour after #6624 merged,
and branched before it — so it ported the pre-#6624 logic:
uiCalendarModels / uiSlotsModels / personalCalendarModels / personalListModels still keyed on
MANAGE_CALENDAR / MANAGE_SLOTS, which EdmIntentGenerator no longer emits.

Nothing is broken today — both paths are live and no consumer is switched, so the JavaScript path
executes. But the moment consumers flip, calendar and slots pages would silently stop being
generated: an empty partition writes no files and raises no error. GenerationParityIT could not
catch it either, because no parity fixture declares a view, so all four partitions can disagree while
every fixture matches.

Fixed by keying the Java collections on calendarView / slotsView (and dropping the calendar
exclusion from personalListModels, matching the JavaScript), plus a views.model parity fixture —
one calendar entity, one slot-picker entity, both keeping their MANAGE layout. Confirmed to be a real
guard: with the ModelGenerator change reverted the case fails, naming the absent
AppointmentSlotsPage.js and Appointment-slots.html; with it, both pipelines agree.

Covered by EdmIntentGeneratorTest (a slots document master keeps MANAGE_DOCUMENT and carries
slotsView plus the slot* metadata), the emission oracle (whose fixture gained a slots document:
the /Visit picker landing route, /Visit/list, /Visit/create resolving to the DOCUMENT editor, and
both toggles) and GenerationParityIT.

🤖 Generated with Claude Code