can://<app>/java/… : move the app outermost and give the graph root its id #244

Plan (optional)

docs/design/plans/2026-09-07-can-uri-app-outermost.md. Spec: codellm-devkit/.github → docs/design/specs/2026-09-07-can-uri-app-outermost.md (.github#68).

Problem

Two identity defects, fixed together because they share one migration.

The deployment unit is not part of the id. can://<lang>/<app>/… buries the app inside the id, so for a multi-service application the graph is queryable but not addressable, and one unit spanning two languages fragments into unrelated id roots.

The graph's application root has no id at all. analysis.json emits application.id = can://java/daytrader8, and V2GraphProjector drops it: :JApplication merges on name, the raw --app-name. Consequences, all live:

• Two services analyzed under one --app-name silently merge into one node.
• The root cannot be reached by id, though every other v2 node is keyed on one.
• RowBuilder attaches the :JCanNode index anchor only to values starting with can://, so the root never gets it — it is the one node the prefix-scoped destructive statements structurally cannot reach.

Scope boundary

In scope: codeanalyzer-java only, shipping in 3.1.1.

Out of scope, by decision: codeanalyzer-python, codeanalyzer-typescript, python-sdk, docs. The maintainer's call, recorded in spec §6 with its costs — chiefly that the grammar fragments until the siblings follow, so a cross-language database will hold two id shapes and the cross-language delete scope will not yet work.

Goals

• CanId mints can://<app>/java/…; can://<app>/artifact/…; can://<app>/java/@external/…
• L2CallGraph:267 and L3WalaOverlays:375 stop matching ids by their language prefix
• :JApplication declares and merges on id, keeps name as a display property, and gains the :JCanNode anchor
• The uniqueness constraint moves from j_application_name to j_application_id
• analysis.v2.schema.json admits only the new shape
• 92 fixture references migrated, composing ids rather than hard-coding them
• schema.neo4j.json regenerated; README §4 updated

Caveats and known risks

• V2SchemaCatalog.SCHEMA_VERSION stays 2.0.0. docs(schema): stop calling the graph contract 2.2.0 #238 recorded "do not bump this to advertise them"; the graph re-baseline is Scope every destructive Neo4j statement on the can:// id prefix; retire _module .github#50's.
• The payload schema_version is an open decision (plan Task 7). Leaving it at 2.0.0 makes an incompatible id change undetectable; moving it to 3.0.0 re-creates the unilateral drift that was undone once already. The plan recommends moving the payload version only, and says to confirm before implementing.
• Old and new ids do not collide, so re-pushing an existing database produces a second disconnected copy rather than an update — and the prefix-scoped delete cannot remove the old copy, because it scopes on the new prefix. Pre-3.1.1 roots have no id at all, so neither prefix match reaches them. The plan carries the three Cypher statements needed.
• A breaking id change ships under a PATCH version. Accepted: python-sdk release/2.0 pins codeanalyzer-java==3.1.0 exactly, so it is insulated until deliberately bumped — and that bump is a fixture migration, not a version edit.
• L1Cache already discards on analyzer-version change, so 3.1.0 → 3.1.1 covers cache invalidation.

Definition of done

• On daytrader8 at -a 1: application.id is can://daytrader8, and every symbol_table module id starts with can://daytrader8/java/.
• No emitted id matches ^can://(java|artifact)/ — the old shape is gone, not supplemented.
• Every projected can://-keyed node is the root or sits under can://<app>/, checked by query.
• Two applications projected under different names produce two distinct :JApplication nodes; the same name twice raises a uniqueness violation rather than merging.
• Conformance green at every level; --emit schema output matches the checked-in snapshot.