InMemoryArtifactService ignores the "user:" namespace convention — user-scoped artifacts are wrongly session-scoped #1460

Bug

InMemoryArtifactService does not implement the user:-prefixed filename convention that the rest of the artifact-service contract relies on: a filename starting with user: is meant to be stored once per (appName, userId) and be visible from every session for that user, not just the session that saved it.

Both other implementations in this repo already do this correctly:

• GcsArtifactService.getBlobPrefix() stores user:-prefixed filenames under appName/userId/user/filename/..., independent of sessionId.
• adk-python's InMemoryArtifactService._artifact_path() does the same ({app_name}/{user_id}/user/{filename}), and list_artifact_keys unions the session-scoped and user-namespaced prefixes.

InMemoryArtifactService.java, however, keys everything by (appName, userId, sessionId, filename) unconditionally:

private Map<String, List<Part>> getArtifactsMap(String appName, String userId, String sessionId) {
  return artifacts
      .computeIfAbsent(appName, unused -> new HashMap<>())
      .computeIfAbsent(userId, unused -> new HashMap<>())
      .computeIfAbsent(sessionId, unused -> new HashMap<>());
}

Repro

InMemoryArtifactService service = new InMemoryArtifactService();
service.saveArtifact("app", "user1", "session-a", "user:profile.txt", artifact).blockingGet();

// Same user, different session — should see the same user-namespaced artifact.
Optional<Part> result = service.loadArtifact("app", "user1", "session-b", "user:profile.txt")
    .map(Optional::of).defaultIfEmpty(Optional.empty()).blockingGet();

// Actual: result is empty. Expected: result contains the artifact saved from session-a.

The same gap applies to listArtifactKeys (a user:-namespaced artifact saved elsewhere never appears) and deleteArtifact/listVersions (they silently no-op / return empty against the wrong session-scoped key instead of touching the real user-scoped entry).

Impact

Any application relying on InMemoryArtifactService (the default in tests, samples, and quick local runs) for cross-session, per-user artifacts (e.g. a user profile or preference file meant to persist across conversations) silently loses that data the moment a new session starts — with no error, since the tool call still succeeds, it just operates on an empty/wrong scope.

Fix

I have a fix + regression tests ready (keys the in-memory map the same way GcsArtifactService keys GCS blobs, and unions the session/user prefixes in listArtifactKeys) and will open a PR shortly.