feat(errors): carry a log-safe message variant on the error

[smartive-nicolai]

Why

Follow-up to #557, which fixed the wrong half of the problem.

#557 suppressed the display inside getTechnicalDisplay itself, so it disappeared from the message the caller receives as well. That is the half that should not change: whoever triggered a failed delete or restore has to know which record is meant, and a bare id does not tell them — least of all a non-admin role, which does receive these messages. A log is the only place with no business keeping the name.

What

sensitiveDisplay keeps exactly its current meaning — the model author's declaration that a display holds personal data — and is consumed differently. The error now carries a second, log-safe variant of its own message:

message:    User "Jane Doe (jane@example.com)" (0b7e…) is not deleted.
logMessage: User 0b7e… is not deleted.

• logMessage sits on the GraphQLError base, so ForbiddenError, NotFoundError, UserInputError and PermissionError all inherit it.
• It is a class field, not an extension. Extensions are serialized to the client, so carrying it there would change the response payload — the exact thing this PR exists to avoid.
• getTechnicalDisplay goes back to always quoting the display (29.3.3 behaviour); the suppression now lives in the new getLogSafeTechnicalDisplay.

How the throw sites stay honest

The prose is written once and rendered twice, through either display renderer:

throw forbidden((display) => `${display(model, entity)} is not deleted.`);

technicalMessage(build) returns { message, logMessage }; forbidden(build) wraps that in a ForbiddenError. Because both variants come from one template, they cannot drift apart — and a message that names several entities has each of them redacted, which matters for the restrict and cascade messages, since those name two.

All eight display-bearing throw sites in resolvers/mutations.ts are converted. resolvers/resolver.ts:73 is left alone deliberately: it builds its display from { id } only, so there is no display to suppress.

For consumers

Anyone who adopted 29.4.0 and set the flag gets their client-facing message back, and should switch to logging logMessage:

catch (error) {
  console.error(error instanceof GraphQLError && error.logMessage ? error.logMessage : error);
  throw error;
}

Verification

• npm run lint clean, tsc --noEmit clean, unit suite 163/163.
• tests/unit/technical-display.spec.ts rewritten for the new split: the caller-facing renderer keeps the display including for a sensitive model, the log-safe renderer drops it, a non-sensitive model is identical in both variants, and a two-entity message has both redacted.
• No api snapshot changes: no test model sets sensitiveDisplay, and this restores the message shape those snapshots already record.
• Docs updated (docs/docs/2-models.md) — the flag's section now describes what it does and does not affect.

Note

The delete dry-run payload is untouched. Those displays are what an admin confirms a deletion against, and the dry-run is not a log.

[github-actions]

🎉 This PR is included in version 29.6.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀