A provision names the engine, because a consumer is coupled to one

Provisions were named after roles: provides "database", requires
"database". Nothing distinguished engines, so a module written against
PostgreSQL could be matched to a provider of SQL Server, resolve as
satisfied, deploy, and fail on its first query — with nothing
connecting that error back to a match made elsewhere by something that
believed it had done its job.

The failure is in the direction that hides. Refusing on ambiguity
exists precisely so this does not happen, and the generic name walked
around it: with one provider of each name nothing is ambiguous, so
nothing is asked.

How it got in: every resolver test had exactly one provider per name,
so no mismatch was expressible and none was caught. The fixtures agreed
with the design — the same fault as the imagined test output in
04-ISSUES/005, at the level of a name.

Refused rather than documented, because the old naming *was* the
documented convention. Providing database/db/sql/sql-database is now a
parse error naming what to write instead.

The rule is about coupling, not specificity everywhere: route and
resolver stay role-named, because a consumer genuinely cannot tell
which proxy answered. novox/hq ADR 0027.

internal/link/enrol_shape_test.go

@@ -77,7 +77,7 @@ func TestWhatANodeSaysWhenItJoinsIsWhatThisMeshReads(t *testing.T) {
 		t.Fatal(err)
 	}
 
-	secret, err := inv.SecretFor(ctx, "database", request.Node, "the-other-end")
+	secret, err := inv.SecretFor(ctx, "postgres-database", request.Node, "the-other-end")
 	if err != nil {
 		t.Fatalf("nothing could be sealed to a key that arrived from a real node: %v", err)
 	}