explore: self at module top level (import time) #460

Summary

Exploratory: should self resolve during a module's top-level evaluation (import time), attributed to that module?

Current behavior

Module files are imported outside any instance context, so a top-level self.* access throws RUNTIME_NO_ACTIVE_CONTEXT_SELF (default async runtime). Example: a file added via api.slothlet.api.add(...) whose body calls self.slothlet.permissions.principal.register(...) fails the add with MODULE_IMPORT_FAILED.

Slothlet api files have always been leaves the host calls; all self use lives inside functions, and routines (initialize, etc.) exist for setup work. So this may be a dead end — top-level code with side effects on the composed api risks ordering errors (the tree is mid-build during import), reload double-execution, and lazy-mode materialization surprises.

Why look at it

Import-time registration would let a scoped api.slothlet.api.reload(moduleID) re-register state the module owns (e.g. #459 principals) with the reloaded code automatically, instead of requiring the module's setup routine to run again.

Questions to answer

• Can import run inside the instance context with the module's identity, in both runtimes and both modes?
• What is safely reachable through self while the tree is still being built?
• Does lazy mode (import on first access) make import-time side effects fire at unpredictable times?
• Is the routines mechanism already the right answer (document it as such and close)?