Bearer token parsing drops the user id's first character

Every module downstream of get_current_user_id -- the stream generator, the publisher, the Redis key helpers -- treats whatever string this function returns as the identity for that connection. If a client authenticates with Authorization: Bearer alice and this function hands back a mangled id instead of "alice", that connection is durably, silently subscribed to a different user's notification stream than the one everyone else means when they say "alice." Two different ways of supplying the same identity -- the Authorization header vs. the ?user_id= query param the browser test page uses -- would authenticate the same human as two different users who never see each other's notifications, with no error and no log line pointing at why.

get_current_user_id slices the Authorization header one character too far past the "Bearer " prefix, so the returned user id is missing its first character.

1. cd fastapi/sse_notifications
2. python3 -c "import asyncio; from app.auth import get_current_user_id; print(asyncio.run(get_current_user_id(authorization='Bearer alice', x_user_id=None, user_id_query=None)))"
3. Observe: prints lice, not alice.

len("bearer ") + 1 reads like a plausible "be careful not to include the space" adjustment to someone skimming the line -- it's an off-by-one that looks more careful than the correct version, which is exactly what makes it easy to wave through in review. It's also the kind of bug that a unit test calling the dependency function directly catches instantly, but that an integration test using a fixed, memorable test username can easily miss if nothing ever compares the returned user id against the sent one.

Work out exactly how many characters are in the literal string "bearer " (the same one .lower().startswith(...) just checked against), and compare that to what's being passed to the slice.