test: read the test nanopublications from the nanopub test suite

[ashleycaselli]

Closes #620.

Nanopublications used as fixtures belong in the nanopub test suite, where every implementation reads them from, rather than being copied into each consumer. #619 did that for the grlc query template it needed; this is the rest of them. They were not all the same kind of thing, so it is not one move repeated five times:

fixture	what happened
np-grlc-query.trig	Deleted, read from the suite. Byte-identical to valid/signed/RA6T-….trig there already — pure duplication. GrlcQueryTest and NanopubElementTest repointed.
np-statusline-example.trig	Moved to the suite as valid/signed/RA58Ycj….trig: Nanopublication/nanopub-testsuite#6, since merged. StatusLineTest reads it from there.
np-governed-definition.trig	Kept here — see below.
np-nongoverned-definition.trig	Kept here — see below.
templates/new-style-assertion-template.trig	Deleted. No test referenced it.

The two governance fixtures stay

Item 3 of the issue asked for a decision rather than an assumption, and the decision is that they stay in this repository. They are hand-built, unsigned, and carry placeholder artifact codes (RAAAA…, RABBB…) because they exist to exercise Nanodash's own governance logic — GovernedVersions.findGovernedRef — not to test whether an implementation reads nanopublications correctly. A suite whose stated purpose is validating nanopub implementations is not their home, and an unsigned nanopub with a made-up code has no business in its valid/ folder. That reasoning now sits on the loader in GovernedVersionsTest, so the question isn't reopened from scratch next time.

How the fixtures are reached

Each test resolves its fixture through the connector by artifact code, the way SparqlPlaceholderValidationTest already did — no wrapper of our own in between:

TestSuiteEntry entry = NanopubTestSuite.getLatest()
        .getByArtifactCode(NANOPUB_ID, TestSuiteCategory.VALID)
        .orElseThrow(() -> new IllegalStateException("Not in the nanopub test suite: " + NANOPUB_ID));
return new NanopubImpl(entry.toFile(), RDFFormat.TRIG);

A fixture that isn't there fails rather than skips: it would mean the entry was renamed or removed, and the test is no longer testing what it says it is. The connector downloads the suite once per JVM, so several fixtures cost one download.

Second commit: one stale skip-guard from #619

SparqlPlaceholderValidationTest.theRealQueryTemplateHasItsSparqlFieldRecognised was written while its suite entry was still a pending pull request, so it skipped when the entry was missing. Nanopublication/nanopub-testsuite#5 merged on 2026-08-20, and the guard has been dead weight since — its own comment claims the test "fails rather than quietly skipping" if a later version of the template moves the SPARQL field, which was not true while an absent entry took it out of the run instead. It now throws, like every other suite fixture here.

Checking it

Full run on this branch: 1232 tests, 0 failures, 26 skipped — the pre-change skip count, with nothing skipping on account of the suite any more.

One unrelated flake showed up on an intermediate run and is worth knowing about, but is not from this change: ApiCachePersistenceTest.entryStoreRoundTrip failed once with TempDirDeletionStrategy$DeletionException — JUnit deleting its @TempDir while the persistence thread was still writing into it. Three consecutive reruns of that class pass, and so does the full suite.

The retraction was checked before being proposed to the suite: np check reports Signed and trusty, and the notes it prints alongside (no creation time, no label, no template) are the ones every existing entry in valid/signed/ prints too.

🤖 Generated with Claude Code

https://claude.ai/code/session_014dByNErNfuj4au4r5vMsbf