#3677 extension push: the yanked-dependency warning names a version to move to, and dependency warnings appear in the Unresolved warnings summary

Problem

swamp extension push warns when a JSR dependency's shipped version is yanked (jsr-yanked, added in #3352). It stays a warning: a yanked version that is pinned exactly still installs and runs. It just means the dependency's author withdrew that release. But the warning gives the author very little to act on, and it never reaches the end-of-run summary.

Dry run from main (2026-10-20) of an extension importing jsr:@std/assert@0.225.0:

[WRN] extension·push: Dependency warnings (--yes accepts):
[WRN] extension·push:   "@std/assert": "version 0.225.0 is yanked on JSR"
...
[INF] extension·push: Unresolved warnings:
[INF] extension·push:   adversarial-review-report — ...: No adversarial review recorded ...
[INF] extension·push:     fix: Run the adversarial review and record its report at the path the finding names.

1. The message doesn't explain or suggest anything. It doesn't say what a yank means. It doesn't say that range resolution skips the version. It doesn't name a version to move to, even though JSR has 0.225.3, which is not yanked, and push already has meta.json for the package.
2. Dependency findings are missing from "Unresolved warnings". buildFindingsReport (src/presentation/renderers/extension_findings_report.ts) builds the report from safety and review findings only. So none of the dependency-trust warnings appear there with a fix: line: jsr-yanked, deprecated-version, loose-specifier and not-audited. An author or agent who reads only the summary misses them. The same report closes extension quality and extension info, so check those outputs too.

Proposal

• Reword the jsr-yanked warning. Say the version was withdrawn by its author, and that new range resolution skips it. Name the newest version that isn't yanked, preferring the same major (or the same minor for 0.x) and falling back to the latest. Show this suggestion in the human output and in --json (for example, a suggestedVersion field on the finding). If no other version exists, say so.
• Add dependency-trust findings to "Unresolved warnings", each with a remediation fix: line. For a yanked dependency, the fix is to pin the suggested version. Give deprecated-version, loose-specifier and not-audited remediations in the same style.
• Keep the severity: it stays a warning that --yes accepts. This issue doesn't change what blocks a push.
• Keep --json additive. Don't rename or remove existing fields.

Acceptance

• A dry run of the example above names 0.225.3 in both the warning and the summary's fix: line.
• Each dependency-trust cause appears under Unresolved warnings with a fix, in push, dry run, and wherever else the report renders.
• A UAT item covers the yanked case, extending tests/cli/extension/push_dependency_audit_test.ts.