No coverage measurement, static analysis or contributor guide

[lgnap]

Context

The project's quality tooling is solid where it exists — CI checks two platforms, fails a build
that dirties the tree, and runs both suites. A few gaps remain, all cheap to close, and all of
the same kind: they concern the ability to see the state of the project rather than the code
itself.

No coverage measurement. The table in TESTING.md gives test counts (282 Java, 57 JS),
which is already better than nothing, but a test count says nothing about which lines are
reached. That is exactly what let the core gap (see the dedicated issue) go unnoticed: the
global total looks healthy, the distribution much less so.

No static analysis. No SpotBugs, no Error Prone, no Checkstyle. On code that handles
streams, file descriptors and byte arrays, a SpotBugs pass is worth running once just to see
what it turns up.

The agent module has no tests at all (261 lines, 3 files). It is small and does bytecode
instrumentation, so this may well be deliberate — but it is not written down anywhere, whereas
TESTING.md documents everything else scrupulously.

One CI comment has gone stale. .github/workflows/ci.yml:42 states:

There is no JavaScript test suite to run

while four JS test files exist and run in the web-ui-tests job, in that same file. The
comment correctly explains why the Java job skips the frontend goals; its justification is
what stopped being true. A reader taking it at face value concludes the frontend is untested.

No CONTRIBUTING.md. The project has real and unusual conventions — the
characterization/specification distinction, the KNOWN GAP marking, the rule that a test
changes category only deliberately and never silently. They live in TESTING.md, which is not
where a contributor goes looking for them.

Description

Close these gaps. They are independent of each other and can ship as separate PRs; this issue
is a rallying point, not a unit of delivery.

The CI comment is a one-line fix and can be handled immediately, separately from the rest.

Affected files

• pom.xml — JaCoCo plugin in pluginManagement
• .github/workflows/ci.yml — publish the coverage report, fix line 42
• web-ui/javascript/package.json — --coverage on the test script
• CONTRIBUTING.md — to be created
• TESTING.md — link to coverage, and state agent's status

Implementation plan

1. Fix the ci.yml:42 comment — independent, immediate.
2. Add JaCoCo, publish the report as a CI artifact. Do not set a failing threshold at
   first: measure, then decide. An arbitrary threshold on a project whose coverage is this
   uneven would only block PRs.
3. Add --coverage on the JS side, same reasoning.
4. Run SpotBugs once by hand over core and driver, triage the output, and decide then
   whether it earns a place in CI. Adding it upfront would drown PRs in warnings inherited
   from upstream.
5. Decide about agent: either tests, or a line in TESTING.md saying why there are none.
   Either answer is fine; silence is not.
6. Write CONTRIBUTING.md: how to run both suites, the characterization/specification
   distinction, the KNOWN GAP convention, and what is expected of a PR.

Acceptance criteria

• The ci.yml:42 comment reflects reality
• Java and JS coverage is measured and readable from a CI run
• No blocking threshold is introduced before the measurement has been looked at
• SpotBugs has been run once and its place in CI settled, either way
• agent's testing status is explicit
• CONTRIBUTING.md exists and covers both suites and the testing conventions
• CI green on Linux and Windows, plus the Web UI job

Complexity

S per item taken alone, M for the whole.