vet-dependencylisted

# Vetting a candidate dependency A package's landing page reports the wrong variables. Stars measure attention at some point in the past, release count measures how often a version was published, and the repository's last-push timestamp moves whenever anything touches it. None of the three answers the question that decides adoption: can this package reach the version this project has already committed to, and does it behave correctly when it gets there. The two facts that settle it are both invisible from the README. The first is the queue of pull requests nobody has merged, which measures whether the package can still move. The second is what the library does at runtime with the exact input class this project will feed it, which measures whether moving would help. The subject is a package that is not yet a dependency, characterized empirically before it becomes one rather than described from its documentation. This skill sits beneath `research-it`, which owns source priority, triangulation, and the discipline around absence claims. It owns only how a candidate's health and fitness are measured, and what verdict that measurement supports. Nothing here is language-specific. Three operations differ per ecosystem (resolving a package to its repository, obtaining the published artifact, running an isolated probe) and are catalogued in [references/ecosystems.md](references/ecosystems.md); the forge API calls differ per host and are catalogued in [references/forges.md](referenc