ci(dig-app): lint for space-run corruption in string literals — it has reached shipped user-facing copy 9 times

[MichaelTaylor3d]

Task

Add a CI lint that fails when a Rust string literal contains a run of 4 or more spaces mid-sentence,
because a corruption class keeps reaching shipped user-facing copy and nothing currently catches it.

The mechanism

A backslash line-continuation inside a multi-line string literal is consumed before the file is
written to disk. Rust's \-at-end-of-line normally eats the newline and the following
indentation; when the backslash is gone, the indentation survives inside the string. cargo fmt
then preserves the damage — it is valid formatting of a valid literal.

The result is shipped copy like:

"Your profile is unchanged — you          can change what you typed and try again."
"the string stops          working"
"DIG could not start this creation because one has already                    been started"

Nothing catches it: cargo fmt --check passes, clippy passes, and tests that assert with
contains(...) on a substring that does not span the run pass too.

Measured incidence, 2026-08-18 — this is not hypothetical

Where	Count	User-facing?
profile_edit/mod.rs NOTHING_WAS_SPENT	1	yes — the reassurance under a failed publish
examples/dialog_gallery.rs detail string	1	yes
Across crates/ (test assertion messages)	24	no — only printed on failure
PR #201 confirm/gui/window/pane/copy.rs:785 +6	7	yes — offer card copy

Three separate agents hit it in one session, and one reported losing continuations on three
separate writes. The two shipped instances were caught by a reviewer reading the source, not by any
gate.

Scope

A lint in dig-app CI (extend to other Rust repos if cheap). Detection is a regex over .rs sources
for 4+ consecutive spaces appearing inside a string literal, not at the start of a continuation line.

Two things to get right:

1. Do not flag legitimate \-continuations. A literal broken across lines with a trailing \
   has leading indentation on the next source line that Rust strips — that is correct and common
   here. The lint must look at the literal's value, not the raw source line. A naive source regex
   will produce dozens of false positives and get switched off.
2. Consider limiting the failure to user-facing copy and reporting the rest. 24 of the 31
   instances are test-failure assertion messages where the damage is cosmetic. Failing the build on
   those invites a bulk-suppression commit that also suppresses the real ones.

Test

The lint must fail on a fixture containing a corrupted literal and pass on one containing a
legitimate \-continuation. Both directions — a lint proven only by the positive case will be
switched off the first time it fires on valid code.

Also worth fixing

The 24 assertion messages are worth a mechanical sweep once the lint exists, so the lint starts from
a clean tree. Whitespace-only; no word may change.

Report

The lint's output on the current tree, and confirmation that a legitimate continuation does not trip
it.

---

Moved from DIG-Network/dig_ecosystem#3117 so this repo's own PR can close it (CLAUDE.md §1.3). GitHub refuses
a private-to-public issue transfer, so the body was copied and comment history stayed on the
original.

Orchestrator ticket: https://github.com/DIG-Network/dig_ecosystem/issues/2378