fix(settings): wait for the loader before migrating the retired settings

The one-time import of a pre-0.1.7 `settings.yaml` section never ran. It
started from the `ctx.inject(['settings'], …)` callback, which fires the
moment the settings SERVICE appears — while the loader is still mounting
rows, so `describe()` does not list this plugin's own entry yet, the lookup
returns undefined, and the import bailed on "no form" without a trace.
Upstream's own migration waits (`ctx.root.loader.await()`); this does the
same.

That made every early return of the import invisible, which is how it went
unnoticed: the callback simply produced nothing. It now returns a named
outcome ('imported' / 'no-profile-home' / 'no-form' / 'already-configured' /
'no-legacy-section' / 'rejected') and the caller logs it — anomalies at warn,
the rest at info. The `loader` mirror's `await` is optional so a composition
without the cordis loader still reaches the import instead of aborting the
whole settings face inside the inject callback; the smoke fakes model it.

Verified on the live 3080 instance: after the upgrade the settings form
reports the user's real values back (autoOpenJobs false, workspaceFence
false, the nine-entry tabsEnabled map), where before it reported pure
defaults. The mount lane stays 7/7.

src/context-types.ts

@@ -495,6 +495,11 @@ export interface SidebarSettingsService {
  */
 export interface SidebarLoaderService {
   entries(): Iterable<SidebarLoaderEntry>
+  /**
+   * Resolves once every profile entry has been mounted (the Loader settles).
+   * Optional: a composition without the loader imports immediately instead.
+   */
+  await?(): Promise<unknown>
 }
 
 /** One configured plugin row inside the profile's entry tree. */