Feature: hot-swap module registration without daemon restart

[warren-t-c]

Problem

When running OrgLoop as a long-lived daemon with a registered module, updating the module's routes, connectors, SOPs, or transforms currently requires stopping and restarting the entire OrgLoop daemon process. This causes a brief window where:

1. Inflight sessions may be interrupted — any agent sessions that were actively processing events when the daemon stops will be terminated
2. Events arriving during the restart gap may be missed — webhooks delivered between stop and start have no listener
3. Other modules are impacted — in a multi-module setup, restarting the daemon for one module's changes disrupts all modules

Desired Behavior

Support hot-swapping a module's configuration (routes, transforms, SOPs, connector configs) without restarting the OrgLoop daemon or affecting other registered modules.

Conceptually:

# Update module config in place, then:
orgloop module reload <module-name>
# or automatically detect file changes:
orgloop start --watch

Expected semantics:

• Inflight sessions on the reloaded module should be allowed to drain (or optionally force-stopped)
• New events should immediately route through the updated configuration
• Other modules should be completely unaffected
• Validation should run before applying — reject invalid configs without disrupting the running daemon
• Rollback on validation failure — if the new config is invalid, keep the current config active

Context

This is analogous to how web servers handle config reloads (nginx reload, systemd ExecReload) or how Kafka Connect can add/remove/update connectors without restarting the Connect worker.

For deployments that use OrgLoop as the central event router with many routes and frequent iteration on SOPs, the stop/start cycle creates unnecessary risk of event loss and session interruption.

Possible Approaches

1. orgloop module reload <name> — explicit CLI command that sends a control-plane message to the running daemon to re-read and apply one module's config
2. File watching — daemon watches module directories for changes and auto-reloads (opt-in, with debounce)
3. Control API — REST/RPC endpoint on the daemon for programmatic module management

Approach 1 seems like the simplest high-value addition. Would love to hear thoughts on feasibility and any gotchas around connector lifecycle management during reload.

[c-h-]

maybe don't need a new CLI; just hot swap on idempotent module start invocation