InMemoryArtifactService/GcsArtifactService collide with the reserved "user" segment when session_id is literally "user"

[MUHAMMEDHAFEEZ]

🔴 Required Information

Describe the Bug:

InMemoryArtifactService and GcsArtifactService lay session-scoped and
user-scoped artifacts out in the same flat namespace, using the literal
segment "user" to mark user-scoped artifacts (_artifact_path/
_get_blob_prefix return f"{app_name}/{user_id}/user/{filename}" for
user-namespaced files, and f"{app_name}/{user_id}/{session_id}/{filename}"
otherwise). The reserved literal "user" is never validated against, so a
session actually named "user" writes its artifacts into the same prefix
that is supposed to be reserved for user-scoped ones.

The consequence isn't just a naming collision: list_artifact_keys() for
an unrelated session incorrectly returns filenames that belong to the
"user"-named session, and attempting to load one of those filenames
returns None — the listing and the load disagree, so a caller that
iterates keys and fetches each one gets an unpredictable miss.

Steps to Reproduce:

1. pip install google-adk
2. Run:

import asyncio
from google.adk.artifacts.in_memory_artifact_service import InMemoryArtifactService
from google.genai import types

async def main():
    svc = InMemoryArtifactService()

    # A session literally named "user" -- collides with the reserved segment.
    await svc.save_artifact(
        app_name="a", user_id="u", session_id="user",
        filename="from_session_user.txt", artifact=types.Part(text="x"),
    )
    # A genuinely user-scoped artifact, and an unrelated session "s2".
    await svc.save_artifact(
        app_name="a", user_id="u", session_id="s2",
        filename="user:shared.txt", artifact=types.Part(text="y"),
    )

    print(await svc.list_artifact_keys(app_name="a", user_id="u", session_id="s2"))
    print(await svc.load_artifact(
        app_name="a", user_id="u", session_id="s2",
        filename="from_session_user.txt",
    ))

asyncio.run(main())

Expected Behavior:

session_id="user" should be rejected outright (it's an internally
reserved value), so this situation can't arise. Failing that, at minimum
list_artifact_keys(session_id="s2") should not include filenames that
belong to a different session.

Observed Behavior:

['from_session_user.txt', 'user:shared.txt']
None

list_artifact_keys(session_id="s2") returns from_session_user.txt, a
filename that belongs to session "user", not "s2". Loading it via
session_id="s2" then returns None, since it's actually stored under the
reserved .../user/... prefix.

Environment Details:

• ADK Library Version: main
• Desktop OS: N/A — reproduces regardless of OS
• Python Version: 3.11+

Model Information:

• Are you using LiteLLM: N/A
• Which model is being used: N/A — no model involved, this is the artifact
  storage layer alone

---

🟡 Optional Information

Additional Context:

Surfaced during review of #7030 (a related but distinct bug: session_id
whitespace normalization, fixed by #6958). This is a different root cause —
a reserved literal value, not padding — and does not depend on that fix.

Confirmed FileArtifactService is not affected: it lays session-scoped
artifacts out under their own sessions/<id>/ subtree, distinct from the
user-scoped artifacts/ subtree, so a session named "user" cannot
collide with it there.

Fix proposed in the linked PR: reject session_id == "user" outright in
InMemoryArtifactService and GcsArtifactService.

How often has this issue occurred?:

• Always (100%) — deterministic, no timing involved

[MUHAMMEDHAFEEZ]

Hey @chelsealong — looks like we crossed wires by about 90 seconds, sorry for the noise! I'm the one who filed this issue, and I'd already drafted the fix while writing it up, so I opened #7064 just after your comment landed, before I'd seen it. Definitely not trying to step on your work.

Totally happy to let you take it if you'd rather — just say the word and I'll close mine. Otherwise feel free to take a look at #7064, and whichever one's easier for the maintainers to review can go forward. No hard feelings either way :)

[surajksharma07]

@MUHAMMEDHAFEEZ list_artifact_keys("s2") does hand back a file that only exists because it was saved under session_id="user" and loading it right back returns None. Ran your reserved-word check from #7064 and it cleanly blocks the save up front while leaving normal user-scoped listing intact, nice catch pairing it with the fail-before/pass-after tests. Since @chelsealong may have a parallel fix in flight could you confirm with maintainers which one should move to review so we don't land both?