fix(core): publish in-memory session for CLI SessionAccess

[TDannhauer]

Summary

• Fix fatal SessionAccessor::current() during CLI appInit (e.g. horde-alarms) after the SessionAccess refactor.
• Publish an in-memory HordeSession for setup(false) without calling session_start().
• Guard Nlsconfig session caching with hasCurrent().

Motivation

CLI scripts deliberately skip PHP session files (Horde_Session::setup(false)). After consumers switched to SessionAccess, that left the accessor empty, so language setup and notification handler attach crashed with LogicException.

Changes

• SessionLifecycle::publishInMemory() — publish accessor/injector binding; keep isActive() false (no $_SESSION mirror).
• Horde_Session::setup(false) calls publishInMemory() when a lifecycle is wired.
• Horde_Registry_Nlsconfig skips session cache when no current session is published.
• Unit coverage for both paths.

Test plan

• vendor/bin/horde-alarms completes (exit 0) on a Horde 6 deployment
• SessionLifecycleTest::testPublishInMemory…
• NlsconfigTest cases without established session
• Spot-check a normal web login still starts a real PHP session

[ralflang]

As a consolidated PR I cannot accept this. It's important to fix any CLI breakage but not by making the session mechanism some kind of in memory value bag. The point of session is carrying information and mostly identity and grants between request lifecycles. CLI scripts don't really need this and if they depend on sessions for architecture / DI reasons we should not make this part of our session design but fix it in the consumers.

[ralflang]

See also #207

I re-worked your design a bit. We don't need to introduce a third state where we did not officially start a session but kind of have one. Horde_Session_Null now behaves like a regular legacy Horde_Session shim and interacts with the modern framework.