fix(core): keep Horde_Session::$begin readable after close() (imp#88)

[TDannhauer]

Summary

• Fix Horde_Session::$begin returning 0 after close(), which broke the session.max_time auth check for read-only service scripts.

Motivation

Reported in horde/imp#88: downloading an attachment in IMP returned a 500 (IMP_Exception: User is not authenticated.), even for a fully logged-in user. The attachment download service boots with a read-only session and calls close() right after bootstrap.

Horde_Session::__get('begin') returned 0 whenever the shim's _active flag was false - which close() sets, without clearing the underlying session data. Horde_Registry::checkExistingAuth() uses $session->begin for the session.max_time check:

if (!empty($conf['session']['max_time'])
    && (($conf['session']['max_time'] + $session->begin) < time())) {
    // -> auth check fails
}

With begin collapsed to 0, max_time + 0 is always less than the current Unix timestamp, so this check failed unconditionally for every closed, read-only request once session.max_time was configured - regardless of how recently the user actually authenticated.

Changes

• Horde_Session::__get('begin') now reads through to the modern HordeSession unconditionally. Its data survives close() untouched, so this is safe for both the closed-but-was-active case and the never-started case (falls back to 0 via the existing null handling).
• Added HordeSessionShimBeginTest covering both cases.

Test plan

• vendor/bin/phpunit test/Unit/Session/HordeSessionShimBeginTest.php (2/2 passing)
• Reporter confirmed on their own deployment that this fix resolves the attachment download 500 (see issue comments)