[rennf93]

Java projects never reported their engine version. The agent sends guard_core_version only when AgentConfig.guardCoreVersion is set (Transport.kt:201/251), the default is empty (AgentConfig.kt:248), and the adapters take a user-built agent, so nothing ever filled it. As a result the SaaS could never flag an outdated engine for a Java project.

This ports the Go agent's behavior (agent.go:183-186, version.go:24-38): when the config leaves the version empty, GuardAgent.create fills it from com.guardcore.engine.GuardCoreEngine.VERSION. The value is read by reflection at runtime, because the engine is a compile-only dependency that may be absent, and a direct reference to the const val would inline the compile-time version. A user-set value always wins, and a missing engine yields "" without throwing.

Tests: GuardCoreVersionTest covers the engine version being filled in, a user value winning, and a missing class giving "".

CoverageMoreTest.settleMetricsNilErrorAfterFailedSplit raises its mock body cap from 320 to 350 bytes, because every batch now carries the version field. Recorded with the mock's call log, master at 320 and this branch at 350 produce the identical call sequence [413, 413, 500, 500, 413, 200, 200], so the test exercises exactly the same path.

Local gate: ./gradlew build passes, with 199 tests and 0 failures.

Release: this lands on master only. Agents release in lockstep, so it ships with the next agent train (3.2.4 across all families).

[github-actions]

Thanks for opening your first pull request on guard-agent-jvm!

Quick checklist before review (most of these are enforced by CI, but worth a glance):

• The PR body says Closes #N for an open issue (the issue-link check enforces it); chores take the no-issue label
• ./gradlew spotlessCheck detekt is clean
• ./gradlew build passes
• No blanket @Suppress in non-test code

See README.md for the agent status. Welcome aboard - a maintainer will review shortly.