assert: reduce truncatingFormat limit so large values stay readable (#1801)

[oaksprout]

You set the work. #1801: a failed assert.Len on a large object dumps an enormous unreadable value — and your own suggested direction was to significantly reduce the limit used by assert.truncatingFormat rather than special-casing Len.

It's done. maxMessageSize is now a documented package const of 4000 bytes (down from ~32.7KB). The number isn't arbitrary — it matches the default MaxLength in Gomega's format package, the sibling assertion library that already solved this exact problem. A regression test written before the fix pins the behaviour: a Len failure on a 1M-element slice is ~4.3KB with the truncation marker, versus 32,755 bytes on current master.

Here's the evidence.

• Fresh clone at 001eb794, patch applied, modules downloaded, then the network was disconnected.
• go test -race ./... in a clean golang:1.26-bookworm container: all 8 packages ok, including the new regression test.
• go vet and gofmt clean. No go.mod/CI changes.
• Blast radius quantified: 22 exported assertions share truncatingFormat and now truncate at 4000 bytes — intentional per your framing ("this will prevent very very long output on all assertions... not just Len"), and the existing *TooLongToPrint test family is limit-agnostic by construction, so it all still passes.

Audit trail — an independently checkable record that these checks ran, in this order, before this PR existed

Base commit	001eb7946baf451879253643e4ce4b38eaa0d4a7
Container	golang:1.26-bookworm@sha256:1ecb7edf… (linux/arm64), network off during tests
The patch, content-addressed	record
The verification result, signed by a second key	record
Timestamped sequence	work assigned → work delivered → checks passed

What this proves: the checks ran, in that order, on exactly this patch, before this PR was opened — none of it can be backdated or swapped afterwards. What it doesn't prove: that the fix is right. The two signing keys are distinct but run by the same project, and the record lives on a test network. Correctness is your judgement, which is the point.

Written by an AI agent; reviewed and sent by a human who answers the review. We're testing whether work checked this way is useful to maintainers — blunt feedback welcome, including "don't".

---

Everything below is written by Claude

Fixes #1801.

The old limit (bufio.MaxScanTokenSize/2 - 100) existed only to keep failure messages under go test's 64KB line-scanner cap (the #1525 bug that truncatingFormat originally fixed) — any value well below ~32KB satisfies that, so the constraint no longer needs to drive the number. The change promotes the local var to a documented package const so the reasoning travels with the code.

Notes for the reviewer

• 4000 is a judgement call grounded in Gomega's precedent, not a number you specified — it's a one-line change if you want a different magnitude.
• Downstream code that greps testify output beyond the new truncation point will see shorter messages; that's the intent of the issue but it is a behaviour change across the 22 assertions, not just Len.
• ElementsMatch's separate unbounded formatListDiff path (named tangentially in the thread) is deliberately untouched — happy to file a follow-up.