feat(intent): embedded calendar panel for a composition child inside its master page

[delchev]

What

view: calendar (or view: range / function: Calendar) on a composition child previously did nothing — calendar rendering was PRIMARY-only, which forced real models (the timesheets day-allocation) to remodel the child as a standalone PRIMARY entity just to get a calendar. Now the child stays a detail of its master — the detail registry, the master-FK-filtered controller, its generated form pages, all unchanged — and the calendar becomes how the master renders its panel:

- name: Timesheet
  relations: [{ name: days, kind: oneToMany, to: DayAllocation }]
- name: DayAllocation
  view: calendar
  calendar: { start: day, title: note }
  relations: [{ name: Timesheet, kind: manyToOne, to: Timesheet, composition: true, required: true }]

The master's browse page and the record's edit form render an embedded x-h-calendar in place of that child's detail table: the same master-filtered rows become events; event-click edits the child; an empty-day click creates one with the master FK and the clicked date preset (the shared form presets matching create query params). An empty month renders as a calendar rather than a "no records" note.

How

• EdmIntentGenerator: dependent && isCalendar() → a detailCalendar marker + the calendar* properties on the .model; the layout stays MANAGE_DETAILS and no standalone calendar page is generated. A PRIMARY calendar entity keeps MANAGE_CALENDAR exactly as before.
• detail-register template: the registration carries calendar: { start, end?, title?, color?, view, range }.
• Shared detailPanel (application-core runtime): builds events from the rows using the def's meta — the same Jackson java.time array/epoch conventions as the standalone calendar page — plus the click handlers; non-calendar defs are byte-identical in behavior.
• master-view + form-view templates: x-if branch between the calendar and the table.

slots stays primary-only (a booking page, not a panel).

Verification

Generated project (Timesheet + DayAllocation): the registration carries calendar: { start: 'Day', title: 'Note', view: 'month', range: false } (syntax-checked), both views carry the branch, the served shared panel has the event mapping, the child keeps its detail contract (form pages, filtered controller). Unit test: a dependent calendar child keeps MANAGE_DETAILS + the meta while a primary keeps MANAGE_CALENDAR. Full engine-intent suite green. Visual rendering rides the same x-h-calendar component the standalone calendar pages already exercise.

Unblocks: the timesheets day-allocation returning to its natural master-detail model (the workaround recorded when the calendar views landed).

🤖 Generated with Claude Code