Document --project-root-path and the multi-module story for codeanalyzer-java #11

--project-root-path / -f is undocumented on both docs fronts. grep -rn "project-root-path" returns nothing in either the mkdocs main tree or the astro branch, and codeanalyzer-java's own README carries it only inside the generated usage synopsis (README.md:126).

Two reasons it now needs prose.

1. The flag gained a second effect. codellm-devkit/codeanalyzer-java#268 makes -f redirect the build root, not just dependency resolution, when the input path carries no build file. Before that fix, -i <repo-root> -f <module> resolved dependencies from the module's pom.xml and then compiled against the repo root, found no build file, fell through to Gradle, and degraded to declared call-graph edges only while exiting 0.

2. How -i shapes can:// ids is a live source of confusion. File keys are relativized against -i, and the app name defaults to its basename, so the same file is named differently depending on where you point:

-i app        →  can://app/java/src/main/java/com/foo/Bar.java
-i .          →  can://<repo-dir>/java/app/src/main/java/com/foo/Bar.java
-i . -f app --app-name sample
              →  can://sample/java/app/src/main/java/com/foo/Bar.java

-f has no effect on ids at all — a natural but wrong assumption is that it does. Worth stating explicitly, along with:

• --app-name has no short form, and pins the prefix so it stops inheriting the directory name.
• Switching -i rewrites every id in the graph; it is not a prefix you can strip and re-add.
• Source discovery from -i is recursive, so pointing at a parent directory absorbs every sibling project beneath it into one symbol table.
• Changing --app-name invalidates the L1 cache, since the app name is part of the cache envelope.

Both fronts are the same repo, so please check whether the mkdocs pages and src/content/docs/backends/codeanalyzer-java.mdx (astro) each need it.