feat(api): API handlers from lazy routes + longest-prefix selection; bump @sdcorejs/utils to 1.2.4 - #65

Summary

1. API handlers from lazy routes (new)

SdHttpInterceptor is registered at the root injector and read SD_API_CONFIG once, at construction. So a library that provides { provide: SD_API_CONFIG, multi: true } in an NgModule loaded with loadChildren lost every handler without any error: no headers, no beforeRemote/afterRemote, no error toast. One Portal hit this with four lazy libraries and worked around it by re-registering every library configuration at root.

• Libraries do not change. SdApiHandlerRegistry reads the SD_API_CONFIG entries of every injector that the Router creates for a route: Route.providers, or the NgModule of loadChildren.
  • It walks router.config when the registry is created and on every RoutesRecognized. Registration therefore happens in the same navigation, before guards, resolvers and components run.
  • Each injector is read once with { self: true }. Its entries are removed when that injector is destroyed, which includes the router's injector cleanup in Angular 21+.
  • The Router has no public API for route injectors, so Core reads the Router's _injector / _loadedInjector / _loadedRoutes fields. These fields exist in Angular 19–22, and the same spec runs on all four lines. Values of the wrong type are ignored, so a renamed field disables the feature and does not break the app.
  • Limit: a canMatch guard inside the lazy module runs before its scope is registered.
• SdApiHandlerRegistry (providedIn: 'root') holds runtime registrations. register() returns an unregister function; configurations() is a signal.
• provideSdApiConfiguration(Class | value): EnvironmentProviders is for values, and for scopes the Router does not create. It registers when the scope's injector is created and unregisters on the scope's DestroyRef. Exported from @sdcorejs/angular/services/api.
• The interceptor and SdApiService now resolve handlers per request from the static list plus the registry. Existing root SD_API_CONFIG providers keep working unchanged, and SdApiModule still does not call provideHttpClient.
• Behaviour change (CHANGELOG, with migration note): among matching handlers, the longest matching prefix (origin + path) wins, instead of the first one registered. Ties keep registration order, with root providers first. Host matching itself is unchanged.
• The token alias and blank-host handling already existed here and were not redone. @sd-angular/core 19.0.41 ships the same API but keeps a raw startsWith match; both CHANGELOGs record this difference.

A handler from a lazy route exists only after its route has been navigated to. A shell that calls a library's host itself before that, for example in a guard on a parent route, must keep a root handler for that host. The docs and the CHANGELOG say so.

2. @sdcorejs/utils 1.2.4

1.2.4 fixes the Observable covariance issue upstream (sdcorejs-utils #14).

Verification

• npm run check:sync: passes.

• npm run lint:release on Node 22.22.3: all four lines pass.

• API specs (services/api/**) for each workspace: 123/123 on v19, v20, v21 and v22.

• Full ng test --code-coverage for each workspace:

  Workspace	Result
  v19	5970/5970, exit 0
  v20	5968/5970: 2 SdImageEditor export/label tests failed under full load
  v21	5970/5970, exit 0
  v22	5967/5970: 3 SdImageEditor export tests failed under full load

  Re-run alone, the SdImageEditor specs pass 114/114 on v20 and on v22. They are the load-sensitive tests already seen flaking before this change, and this PR does not touch them.

• If the route tracker is disabled, the 5 new lazy-scope tests fail.

🤖 Generated with Claude Code