fix(manifest): resolve Maven dependencies through Maven's own resolver

[Jeppe Fredsgaard Blaabjerg (jfblaa)]

Summary

The Maven facts extension collected the dependency graph with maven-dependency-tree, then re-resolved each artifact itself, passing the root module's repository list for every node in the tree. Maven resolves each node against the repositories that node's own descriptor lineage contributes, so a dependency served only by a repository declared in one module of a reactor could not be materialized for any other module that reached it.

Aether's local repository also tracks which repository each cached file came from, so not even an already-downloaded copy counted as available: the resolver went to the network, missed, and --with-files aborted the scan on a dependency mvn compile resolves without trouble.

Resolution now goes through ProjectDependenciesResolver — the component LifecycleDependencyResolver holds, i.e. the one Maven's own lifecycle uses to build every project's classpath.

What that changes

• Per-node repositories, dependency management, scope derivation and reactor substitution are Maven's, not a re-implementation. The previous graph wasn't Maven's either: DefaultDependencyCollectorBuilder overrode the session's setDependencySelector / setDependencyGraphTransformer with the tree tool's own.
• Failures come from Maven's own per-dependency errors (getCollectionErrors, getUnresolvedDependencies + getResolutionErrors, and the partial result on DependencyResolutionException), each carrying Maven's message and the dependency's own scope. Fail-closed is kept: an unresolvable dependency still aborts, because a silently missing jar leaves reachability blind to what that artifact contains and under-reports.
• Which artifacts get fetched is a DependencyFilter, carrying over the old guard. A plain --facts run rejects everything, so it collects without downloading; a reactor sibling's jar is never requested at the validate phase the CLI runs, where nothing has been packaged and nothing need be installed. A filtered-out node produces no ArtifactResult, so it lands in neither resolvedDependencies nor unresolvedDependencies and can never be mistaken for a failure.
• Records are unchanged: coordinate ids keep Maven's type rather than Aether's file extension, and versions use the base version so a resolved remote snapshot can't leak a timestamped coordinate no manifest names. Conflict-losing nodes, which a verbose collect (mvn -X) leaves in the graph, are skipped.
• maven-dependency-tree is dropped; the extension jar goes 67K → 26K.

Tests

Two new compat fixtures, both verified to fail on the pre-change jar and pass after:

• repo-inheritance — liba declares the only repository serving demo.scoped:widget; libb reaches it transitively. Pre-change it fails with Could not find artifact … in central. A second phase mirrors central to a widget-less repo and asserts the failure record is emitted, so fail-closed itself is guarded.
• duplicate-failure — several modules failing on the same dependency. Their identical failures collapse in the value-equality accumulator shared across the reactor, which a naive "did this module report anything?" size check reads as silence. Runs offline, so it needs no stub repo and never touches the network.

The Maven matrix now spans 3.2.5 → 4.0.0-rc-6, the range the extension claims to support: 30 assertions (5 versions × 6) all pass. Records verified byte-identical to the previous jar on two real multi-module projects; a plain --facts run against a cold local repository fetches poms only, zero jars.

Second commit

docs(changelog) repairs a pre-existing problem the merge surfaced.

1.1.161 never reached npm (1.1.160 is still latest), so nobody can install what that section described. Its tag and GitHub release are immutable and stay as they are — GitHub generates those notes from the PR list, independently of this file — while CHANGELOG.md documents the published package. The next bump derives 1.1.162 from the reachable tag regardless, so this touches no release tooling.

How the section got there: #1516 wrote its heading as ## [Unreleased] - 2026-08-27, and unreleasedRange() in scripts/release/changelog.mts locates the block by comparing the trimmed, lowercased heading for equality with ## [unreleased]. The trailing date made it miss, so the release found nothing accrued, fell back to commit-derived notes, and inserted its heading above the block it couldn't see — stranding [Unreleased] below a released version.

The commit drops the burned 1.1.161 section, returns the Coana 15.10.25 note to ## [Unreleased] for the next release that actually ships, restores ## [Unreleased] at the top without a date, and leaves out "stop the coana bump from hand-writing versions" — a release-workflow change with nothing for a package user to act on, which only appeared because the commit-derived fallback ran.

The locator's intolerance of a trailing date is left for its own change.

Third commit

docs(bump-coana) pins the recreated [Unreleased] heading to exactly that spelling, with the reason attached.

Tracing #1516: the bump wrote ## [1.1.161](…) - 2026-08-27 — a version heading, which the skill already forbids — and the follow-up correction changed the version to Unreleased but kept the date. The skill said what not to write, not what the heading must look like once recreated, so the partial fix landed on a form the release cannot see.

Note the limit: the bump PR was opened by app/socket-pr-bot, which lives outside this repo, so this commit only governs the in-repo procedure and whoever corrects a malformed heading by hand. The bot still writes a ## [<version>] heading and a package.json version — both of which #1515 forbade — and that needs fixing where the bot lives.