--app-name is not emitted as a name: the application object has no name field, so the graph anchor is unnamed

[balajinix]

--app-name is documented as "logical application name for the graph :Application anchor (default: input dir name)". The value does reach the analysis: it becomes the application id. But no name field is emitted anywhere, so a consumer reading the anchor's name gets null.

Reproduce

codeanalyzer-typescript 1.4.0, on two projects from open-telemetry/opentelemetry-demo:

cants -i src/frontend          -o out-frontend  --app-name frontend          --emit json
cants -i src/react-native-app  -o out-rn        --app-name react-native-app  --emit json

The application object in analysis.json carries these keys, in both runs:

id, kind, symbol_table, call_graph, param_in, param_out,
artifacts, dependencies, unresolved_imports, config_uses,
config_reads, entrypoint_report

There is no name key at all. The supplied value appears only inside the id:

--app-name frontend          ->  id = can://typescript/frontend          name = (absent)
--app-name react-native-app  ->  id = can://typescript/react-native-app  name = (absent)

Why it matters downstream

A consumer that joins application anchors to something else by name (for us: matching an application to the container image running it) has to either treat the anchor as unnamed and drop it, or parse the name back out of the can:// id. We hit the first case: a filter of the form WHERE a.name IS NOT NULL silently discarded the anchor and every module hanging off it, while every other signal looked healthy: nodes present, no errors, queries answering. An absent name is harder to notice than a missing application.

Parsing the id works but makes the id's shape a load-bearing contract for consumers, which it probably should not be.

Suggested resolution

Either emit name on the application object from --app-name (defaulting to the input directory name, as the help text already promises), or reword the help text so it does not describe the value as a name for the anchor.

The first seems preferable given codeanalyzer-python and codeanalyzer-java both name their applications per project.

Note on a related problem that is already fixed

I originally hit this alongside module ids colliding across two projects analysed from one repository into one graph, where the last writer displaced the first. That is fixed as of 1.2.0 (feat(schema)!: per-module language namespace in can:// ids). Confirmed on 1.4.0: the two projects above still share 12 identical project-relative paths, for example components/... entries, but produce zero colliding can:// ids. Recording it here so the fix is not re-reported.