CalendarModule.forRoot does not accept imports, so a host business calendar cannot have dependencies

[fantasywind]

Context

A host that needs real working-day semantics implements BPMBusinessCalendar and registers it through BPMRootModule's businessCalendarProvider, as documented in docs/11-consumer-quickstart.md §2b.

Current behaviour

BPMRootModule.forRootAsync threads options.imports into every sub-module it composes:

NotificationOptionsModule.forRootAsync({ imports: options.imports, ... })
BPMAuthModule.forRootAsync(authOptions)          // carries options.imports
IdentityModule.forRootAsync({ imports: options.imports, ... })
AttachmentModule.forRootAsync({ imports: options.imports, ... })
SignatureModule.forRootAsync({ imports: options.imports, ... })
WorkflowEngineModule.forRoot({ imports: options.imports, ... })

but not into CalendarModule:

CalendarModule.forRoot({ businessCalendarProvider: options.businessCalendarProvider })

and CalendarModule.forRoot has no imports in its own metadata either.

Why this matters

Any realistic calendar has dependencies — the holiday list comes from a repository, a config service or an HTTP client. Because CalendarModule has no imports, a useClass / useFactory provider cannot resolve them, and the documented example in docs/11-consumer-quickstart.md:

@Injectable()
export class HostBusinessCalendar implements BPMBusinessCalendar {
  constructor(private readonly calendarRepository: HostCalendarRepository) {}
}

fails to instantiate unless HostCalendarRepository happens to be exported by a @Global() module.

The workaround is to wrap the calendar in a host-side @Global() module and register it with useExisting, which is easy to miss and is not what the quickstart shows.

Suggested fix

Accept imports on CalendarModuleOptions and thread options.imports through from BPMRootModule, consistent with the other sub-modules.