Function resolve_backend 

pub fn resolve_backend(pool: &AnyPool) -> SessionBackend

Resolves Config::session_driver into the matching, constructed (but not yet prepared - see session_layer’s own ensure_dir/migrate call for that) SessionBackend variant. Split out from session_layer itself specifically so larust_testing::TestClient can build a handle over the same backend a router’s own session layer resolved to, without duplicating the driver-selection logic (and risking it drifting out of sync) - TestClient::acting_as forges a session by writing directly through this handle, bypassing a real /login round trip, so it has to agree with the router on where sessions actually live. Doesn’t call ensure_dir/migrate itself: a TestClient is always built over a router whose own .with_sessions(...) call already ran them, the same “someone else already prepared this” assumption the database branch has always relied on (TestClient::new never called AnySessionStore::migrate either, even before FileSessionStore existed).

Reads Config::session_driver/AppPaths through larust_core:: try_config()/try_paths(), not config()/paths() - the same non-panicking fallback cookie_name already uses, and for the identical reason: a handful of narrow test harnesses build a session- bearing router directly off a bare pool, with no Application::new() call anywhere in the test, so nothing has ever published either singleton. Both fall back to "database" behavior when unset - not "file" - so calling this the way every existing test in this codebase already does keeps behaving identically whether or not an Application happened to be constructed first.