Per-method test coverage: a unit test and a functional test for every provider method #635

Epic: #444 — The resource model.

Every provider method gets a Go unit test and a devlore-test functional test; every compensation companion gets the same. One PR per provider, starting with file.Provider.

Why now

The resource-construction campaign and its successors have repeatedly found defects that only a test at the right altitude would have caught, and several were found by accident:

• SymbolicLink.Exists followed the link, so a deployed link verified as its target (Plan-time claiming: pending entries for string-valued resource parameters; promises recorded; products excluded #585 PR C).
• Remove's *Regular type contradicted its own documentation, and remove_all's *Directory claim was the only thing keeping rm -rf off a file (AnyEntry: claims that assert existence, not kind #616's audit).
• file.Any was never enrolled in pre-flight's verification gate, so its claims were silently skipped (file.move unifies: any kind, no policy, move_directory retires #620 — caught by an acceptance scenario, not by a unit test).
• Unexporting a base silently removed every promoted field from the Starlark surface (The taxonomy reshape: unexported base, AnyEntry variant #617 — caught by an unrelated extension test).

The pattern: behavior that no test names is behavior nobody notices changing. A per-method matrix turns those from lucky catches into guaranteed ones.

The shape

For each provider, per method:

1. A Go unit test exercising the method directly — the contract at its own altitude, including the failure directions.
2. A devlore-test functional test exercising it through a planned graph — the contract as an author meets it.
3. The compensation companion, where one exists: forward, then undo, then the state assertion that proves the undo was real.

For file.Provider specifically: every method that accepts file.Resource must be tested against all three kinds — regular, directory, and symbolic link. That interface is new (#616), and the whole point of it is that kind is the disk's business rather than the author's; a method that quietly misbehaves on one kind is exactly the gotcha the type invites. The link cases matter most, since lstat-versus-stat is where this codebase has already been bitten twice.

Sequencing

file.Provider first — it is the largest surface, the one with a kind axis, and the one every other provider's pattern will be judged against. Then one PR per provider.

A gap analysis comes first within each PR: 3.5.x's status files already carry per-method test matrices, so the work starts by diffing that matrix against the tree rather than by writing tests blind.