fix(tools): emit repo-relative paths in the drift report, never absolute

[juemerson-at-purestorage]

Problem

Reports/PfbApiDriftReport.json and .md are committed artifacts, but the generator emitted absolute filesystem paths into them — 88 occurrences in each file on main.

target.file was always repo-relative. confidence.unresolvedParameters[].file was not: it passed the cmdlet's absolute path straight through.

Two concrete harms:

1. It published the generating machine's home-directory layout into the repo.
2. It made the committed content depend on where it was generated. Regenerating from a git worktree instead of the main checkout rewrote all 88 lines — 174 of 279 diff lines of pure churn, burying the 3 real changes that were actually under review. This was caught while reviewing an unrelated branch, where the noise nearly hid the substance.

Fix

Extracts the relativization Get-PfbGapTarget already performed into a shared ConvertTo-PfbRepoRelativePath helper, applied at both emission sites — one rule, one place to change it. The .md writer renders the same structure, so it is fixed by the same change.

"file": "C:\Users\<user>\...\Public\Bucket\Remove-PfbBucket.ps1"
   ->   "file": "Public/Bucket/Remove-PfbBucket.ps1"

Regenerated artifacts are path-only

88 changed lines per file, verified programmatically to differ by nothing but the path prefix — no semantic change to the report. Both committed blobs now contain zero absolute paths.

Regression guards

Three new tests over the real generated artifacts assert no absolute path survives in unresolvedParameters, in enriched body-property targets, or in the rendered markdown.

All three were mutation-proved: with the helper stubbed to a passthrough, all three fail.

Worth noting — the mutation caught a bug in one of the guards. The target test originally read $g.target.file at gap level, but target hangs off each enriched missingBodyProperties[] entry, so it scanned nothing and passed vacuously. It now reads the correct nesting level and asserts a non-zero population (403 targets) so it cannot silently go hollow again.

Testing

Suite 632 / 4 / 2, against a 629 / 4 / 2 baseline at cd7e4a6 — exactly the three new guards, zero regressions.

The 4 pre-existing failures are stale pinned acceptance figures in Tests/Build-PfbApiDriftReport.Tests.ps1 (context_names, allow_errors, phantomFieldCount, high-confidence-13). They predate this branch and are deliberately untouched — no pinned figure was adjusted to make anything pass.

Note for anyone reproducing these numbers: tools/specs/ is gitignored, so a fresh worktree has no OpenAPI cache and ~27 drift tests skip silently, giving 606 / 0 / 29 instead. Copy the cache in before measuring.

Compliance-sensitive callout

This changes the content of two committed generated artifacts. It does not change any cmdlet, any wire behaviour, or the semantic content of the drift report.

🤖 Generated with Claude Code