fix(cli): start lifetime modules before use in CLI commands

[A386official]

Bug

maddy imap-acct and maddy creds CLI subcommands crash with a nil pointer dereference (SIGSEGV) when used with storage.imapsql:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0xeb5430]

goroutine 1 [running]:
github.com/foxcpp/go-imap-sql.(*Backend).UpdateManager(...)
        github.com/foxcpp/go-imap-sql@v0.5.1-0.20250124140007-8da5567429d5/backend.go:343
github.com/foxcpp/maddy/internal/storage/imapsql.(*Storage).EnableUpdatePipe(...)
        internal/storage/imapsql/imapsql.go:348
github.com/foxcpp/maddy/internal/cli/ctl.openStorage(...)
        internal/cli/ctl/moduleinit.go:96

Root Cause

getCfgBlockModule() calls RegisterModules() then c.Modules.Get(), which triggers lazy Configure() on the target module. However, it never calls Start().

For storage.imapsql, Start() is what initializes the Back field (the go-imap-sql backend). Without it, Back is nil. When openStorage() then calls EnableUpdatePipe(), it dereferences store.Back.UpdateManager() on a nil Back, causing the SIGSEGV.

The server path works correctly because moduleMain() calls c.Lifetime.StartAll() after configuration, which invokes Start() on all LifetimeModule instances. The CLI path was missing this step.

Fix

Call c.Lifetime.StartAll() in getCfgBlockModule() after the module is retrieved from the registry. This ensures all lifetime modules (including the storage backend and its dependencies) are fully started before the CLI tries to use them.

Also wire up c.Lifetime.StopAll() on error paths in openStorage() and openUserDB() so that started modules are cleaned up when the type assertion fails.

Closes #815