fix(internal/harness): size the report columns to the results

[OmarAlJarrah]

Summary

harness.Report laid its table out with printf field widths chosen by eye:

_, _ = fmt.Fprintf(&b, "%-40s %-20s %s\n", r.Spec, r.Outcome, r.Detail)

r.Spec is a spec path, and nearly every spec the sweep renders is longer than
40 characters, so the outcome was not a column at all — it landed wherever the
path happened to end:

git ls-files testdata | grep -E '\.(ya?ml|json)$' | grep -v '\.golden\.' |
  awk 'length($0) > 40' | wc -l   # against the same list without the awk

testdata/conformance/openapi/allof-boolean-branch.yaml ok
testdata/conformance/openapi/allof-inheritance.yaml ok

The trailing %-20s also padded every line with spaces the report had no use
for, since most lines have no Detail to follow them.

Both widths are now measured from the results being rendered, the way the CLI's
command column is derived rather than declared. Counting is in runes, which is
the unit fmt's %-*s pads in — a byte count would over-pad a non-ASCII path.
A line whose Detail is empty stops at its outcome instead of padding out to a
column with nothing to its right; that is also what sizes the outcome column,
since only rows carrying a Detail have a neighbour to line up against.

After:

testdata/conformance/openapi/allof-boolean-branch.yaml          ok
testdata/conformance/openapi/allof-inheritance.yaml             ok

Test plan

Three new tests in internal/harness, each confirmed to redden against the
defect it names rather than accepted because it went green:

• TestReport_ColumnsAreSizedToTheResults — the outcome and detail columns
  start at the same offset on a long-path line and a short-path line, and the
  spec column is exactly the longest spec wide. Restoring %-40s %-20s %s
  fails it on both offsets.
• TestReport_LinesAreNotPaddedPastTheirLastColumn — no line carries padding
  after its last column. Restoring the old format fails it.
• TestReport_WidthsAreCountedInRunes — an eight-rune, eleven-byte path is
  padded to eight. Swapping utf8.RuneCountInString for len fails it with
  expected: 9, actual: 12.
• TestReport_OutcomeColumnIsSizedOnlyByLinesThatUseIt — the outcome column is
  measured against the results that carry a Detail and no others. Sizing it
  from every result passed the rest of the suite while padding each detail out
  past a column standing empty on the line that set its width.
• TestReport_IsStableAndSorted now also checks the caller's slice, which the
  copy exists to protect; reading only the rendered string let an in-place sort
  pass.
• TestReport_ResultsNamedAlikeKeepTheirGivenOrder — two results carrying one
  spec name render in the order they were given. Report documented a "stable"
  summary and sorted with sort.Slice, which is not; it uses sort.SliceStable
  now, for the reason irverify already does. The case scatters its duplicates
  through enough distinct keys that the sort must partition around them, since an
  unstable sort leaves a short slice to an insertion pass and short-circuits one
  whose keys are all equal — a two-result case would pass either way.

Report's doc comment also claimed "one aligned line per spec", which is not
what a Detail holding newlines renders, and the round-trip oracle's holds
several: it prints both encodings. It now says one line per spec plus one for
each newline a Detail carries, and that the columns line up on the line each
result begins.

columnStart fails when a column is absent, so two missing columns cannot
compare equal and assert nothing.

main is merged in, and the full gate is green on the merged branch: gofmt,
go vet ./..., golangci-lint run (0 issues), go build ./...,
./scripts/check-coverage.sh.

Closes #309