Design: the settings plugin module has become de facto framework; make the dependency explicit #500

Tier 2: structural (needs a design note first)

Problem

SM009 forbids framework/* from importing plugin modules. Hosting depends on settings anyway, through string imports the AST check can't see:

• _preapp_config.py:59: importlib.import_module("settings.constants")
• _lifespan.py:49-50: "settings.service", "settings.store"
• _hydrate_step.py:27: "settings.hydrate"
• _secret_key.py:27,78: raw SQL into the settings module's table, with hard-coded column names

On the module side, settings/registration.py:25 (register_module_settings) is the settings-registration path for nine modules: api_tokens, background_tasks, branding (18 imports), file_storage, keycloak, site_lock, tenants, users, and others.

Cost

• No module can run without settings, but nothing declares or enforces that.
• A schema change in settings silently breaks secret-key storage and pre-app config. Both fail into broad except blocks (see Tenancy fails open when the pre-app host-settings read hits a transient DB error #494, One invalid stored host setting crashes boot on every worker #497).
• SM009 gives false assurance.

Options

1. Move the settings registry, store and hydration into simple_module_core or simple_module_hosting behind a small SettingsBackend protocol. settings keeps only the admin UI.
2. Accept that settings is a required framework dependency: import it statically, declare it, and drop the importlib indirection.

Option 1 is cleaner. Option 2 is honest and cheap. The current state is the worst of both.

Also

Extend SM009 to flag importlib.import_module("<plugin>...") string literals in framework/*.