fix(java): java codegen versioned namespace

[ospreyboi]

Closes #159

Hello!!
I was exploring the Accord Project codebase
and stumbled across this bug. I tried generating Java code
from a versioned Concerto model and noticed the version was just
silently dropped from the package name
which makes the output
incorrect and breaks downstream consumers.

Turns out parseNamespace() already returns the version, it just
was not being used! The fixing was surprisingly small — just two lines
changed to destructure version alongside name and include it
in the namespace string when present.

I also added a dedicated test case for versioned namespaces and
updated the snapshots so everything is consistent.

Changes

• lib/codegen/fromcto/java/javavisitor.js — fixed startClassFile
  and import generation to include version in namespace when present
• test/codegen/fromcto/java/javavisitor.js — added test for versioned namespace
• Updated snapshots to reflect corrected output

[mttrbrts]

Thanks for fixing this! Before we merge, can you confirm the generated output compiles successfully with Javac?

This comment was generated by AI on behalf of @mttrbrts.

[mttrbrts]

@copilot resolve the merge conflicts in this pull request

[mttrbrts]

Thank you for taking the time to dig into this, @ospreyboi — the issue is a real one and the instinct to use parseNamespace() was correct.

Unfortunately the approach hits a hard constraint in the Java language spec: package names and import statements may only contain valid Java identifiers separated by dots. The @ character is not permitted, so output like:

package concerto.decorator@1.0.0;
import concerto@1.0.0.Concept;

causes javac to error with ';' expected and '.' expected on every file, and the verify-java CI job confirms this.

There is no simple escaping mechanism that would work cleanly here — the most obvious alternatives (e.g. v1_0_0 suffix, a nested v1 sub-package) all result in names that don't round-trip back to the original Concerto namespace in a useful way and would be confusing to Java consumers.

The version is intentionally dropped in the current codegen to produce idiomatic, compilable Java. Closing this PR and the linked issue #159 as won't fix — this is a language-level limitation rather than a bug.