Thanks for the PR! The scope is right — the runtime array handling already landed on master with #23013, so limiting this PR to the type widening, the two remaining raw resource reads in useDropTarget, propTypes, demo hardening, and tests is exactly what #23014 asks for. A few things worth a look before merging.

🟡 Timeline aria-labelledby breaks for multi-resource events

This one lives in a file the diff doesn't touch: the Timeline builds each event's aria-labelledby from the raw resource value (EventTimelinePremiumContent.tsx, `...TitleCell-${occurrence.resource}`, same pattern for the placeholder). The title cell ids are built from a single resource id, so with an array this interpolates to ...TitleCell-r1,r2, which matches no element — multi-resource events lose their accessible name in exactly the one-row-per-resource rendering this PR enables. Note the instance rendered in each row should probably be labelled by that row's title cell rather than by the occurrence's own resource. If we prefer, this can also move to #23017 with the rest of the multi-row correctness work — but let's not lose it.

🟡 The event-level "visible if ≥1 resource visible" semantics is only tested through a selector that masks it

groupedByResourceList already skips hidden resources as rows, so the "all assigned resources hidden → empty response" test passes even if the event-level visibility filter in getOccurrencesFromEvents were removed. The null-resource test is weaker still: the response is empty either way, so the not.to.include assertion passes vacuously (as its own comment hints). The semantics that matters for the EventCalendar — the event renders (once) as long as at least one assigned resource is visible — is decided in getOccurrencesFromEvents, so it would be better pinned by testing it directly; event-utils.test.ts already covers the two helpers and is a natural home.

🟡 Unnecessary cast in the test builder

In EventBuilder.resources(), the (this.event as { resource?: unknown }) cast shouldn't be needed — SchedulerEvent['resource'] is widened in this same PR, so the direct assignment typechecks. The JSDoc also mentions the processed-event field, but this sets the raw event one.

🟡 JSDoc on the widened fields still describes a single id

In models/event.ts, both the SchedulerEvent field and the processed-event variant still read "The id of the resource this event is associated with." after the type change. The docs pages are deliberately left untouched (we're not announcing multi-resource yet), but the type's own JSDoc should match its signature.

ℹ️ The modified fallback branches in useDropTarget are unreachable

Heads-up, nothing to fix here: the resourceId = null default in the destructuring means resourceId === undefined can never be true, so the two getPrimaryResourceId fallbacks are dead code (pre-existing structure). The change is still the right minimal edit to keep the file compiling against the widened type — just noting the new code path can't be exercised by tests.

ℹ️ Known array-collapsing paths remain until #23016/#23017

Dragging a multi-resource event in the Timeline (even a pure time move within its own row) writes a single row id back to resource, and saving the dialog collapses to the primary id. Both are explicitly deferred in the umbrella plan (#23017 non-destructive DnD, #23016 dialog editing) and the feature is dormant/unannounced, so this ships as-is per the plan — just confirming it's intentional.

Also: the test_e2e failure looks unrelated — it died at the "Build packages" step while test_e2e_react_18 and every other job passed; a re-run should clear it.

🤖 Review generated with Claude Code