Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: InMemorySessionService.create_session() checks for a duplicate id before trimming it, so a whitespace-padded id silently overwrites an existing session instead of raising AlreadyExistsError #6887

Problem:
InMemorySessionService._create_session_impl() checks whether a session already
exists using the raw session_id, and only strips whitespace from it
afterward, right before using it as the storage key. A client-supplied id
that differs from an existing one only by surrounding whitespace (e.g. a
trailing "\n" picked up from a file, CSV column, or env var) therefore
misses the duplicate check and silently overwrites the existing session,
wiping its events and state, with no exception and no log line.

sqlite_session_service already strips the id before running its
duplicate check, so this is an inconsistency between backends rather than
intended behavior.

Solution:
Move the strip() to the top of _create_session_impl, before the
duplicate-id check, and simplify the later normalization (which no longer
needs to re-strip) to just falling back to a generated id when blank. Net
change is -3 lines.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

Added two tests to tests/unittests/sessions/test_session_service.py,
instantiating InMemorySessionService directly (this is backend-specific
behavior, not something the shared cross-backend session_service fixture
should assert, since database/redis normalize differently and that's a
separate, larger discussion):

• test_create_session_with_padded_duplicate_id_raises_error — creates a
  session, then asserts that creating again with the same id padded in
  whitespace raises AlreadyExistsError instead of clobbering the original
  session's state.
• test_create_session_with_blank_id_generates_one — asserts a
  whitespace-only id is treated as no id (still generates one), guarding
  the simplified fallback logic.

I confirmed the first test fails on the unfixed code (DID NOT RAISE AlreadyExistsError) and passes after the fix, so it actually exercises the
bug rather than passing vacuously.

$ pytest tests/unittests/sessions/test_session_service.py
================== 252 passed, 2 xfailed, 3 warnings in 4.88s ==================

The 2 xfailed are pre-existing, documented Redis divergences unrelated to
this change.

Also ran pyink --check, ruff check, isort --check, codespell, and
mypy --strict on both changed files — all clean.

Manual End-to-End (E2E) Tests:

Ran the reproduction from the issue directly against InMemorySessionService:

Before the fix:

before: order-42 2 {'cart': ['book']}
second create returned: 'order-42' (no exception)
after : order-42 0 {'cart': []}

(the second create_session call silently destroyed the first session's
2 events and its cart state)

After the fix:

before: order-42 2 {'cart': ['book']}
second create raised: AlreadyExistsError - Session with id order-42 already exists.
after : order-42 2 {'cart': ['book']}

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

Scope note: the issue also flagged that database and redis backends
normalize session_id differently (or not at all), which is a separate,
larger behavioral question across BaseSessionService implementations.
This PR intentionally only fixes the in_memory inconsistency against
sqlite's existing (correct) behavior, and leaves the cross-backend
normalization contract as a follow-up.