docs: x-FuSa spec v1.15.0 — attestation carry-forward MUST + implementer guidance

[SoundMatt]

Summary

Follows a deep audit (this session) of go-FuSa/c-FuSa/py-FuSa/java-FuSa's own v1.13.0/v1.14.0/v1.14.1 conformance work — 23 real defects found. Most were implementation bugs against already-clear MUSTs (tracked as issues against each tool, not a spec problem). Three patterns recurred across independent implementations often enough to indicate the spec itself needed to say more:

• New §1.6.2 MUST — attestation carry-forward. The spec defined the attestation data model and staleness-via-hash-mismatch logic, but never required a regenerating command to preserve an existing attestation. One tool's otherwise-correct "always rebuild from scratch" implementation silently wiped every human attestation on the very next run — a real spec gap, since nothing made carry-forward mandatory. Fixed.
• New §1.6 rule 4 guidance (SHOULD) — reuse exclusion logic. Three of four audited tools' scanners independently counted test fixtures or stdlib/builtin calls as real project components, violating an already-explicit MUST. Added guidance to reuse the same exclusion logic trace's function-coverage denominator already needs.
• New §9.2 MUST — coveragePct ≤ 100. Two tools produced impossible values (111.9%, 500%) from exactly the rule-4 violation above. Made explicit as a checkable invariant.

SpecVersion bumped 1.14.1 → 1.15.0. FuSaOps' own fmea/tara/hara/safetycase/sas packages already implement carry-forward correctly (verified by existing tests from PR2 earlier this session) — no FuSaOps code changes needed here, just the spec catching up to what was already correct.

Test plan

• go build ./... / go vet ./... — clean
• go test ./... — all pass (doc-only + version-constant change)