v0.2.2 — the mark line is recognised by structure

One defect, in the mark layer. pip install -U folder-nature.

What was wrong

stamp_text() is documented as idempotent — "an existing mark is replaced". It was not, once
anything had indented the channel-A mark line:

	channel-A frames in the file
after stamping	1
re-stamp, untouched	1
re-stamp after the line is TAB-indented	2

The old frame survived, a second was added, and the file still verified as authentic — so
the previous payload stayed embedded and extractable beside the new one. That is the wrong
failure for an attribution layer: it accumulates history nobody chose, and it looks healthy
while doing it.

gofmt indents with tabs and Go is a supported language, so this was reachable, not theoretical.

Why it happened

The mark line was recognised by a character-set question:

does this line consist only of comment characters, spaces and zero-width characters?

That is a proxy for "is this a mark line", and it answers wrong the moment the line carries any
other character — a tab, say. It is now recognised structurally: an optional comment prefix,
one sentinel-delimited zero-width frame, and nothing else. Indentation of any kind stops
mattering.

The new recogniser is also stricter, which is the safe direction: it no longer removes a line
it did not write. The old check would have eaten a line of code that merely contained a frame.

How it was found

By reading the lint findings instead of trusting them. A linter said "stripped is assigned to
but never used" — reported as dead code. It was an omission: the author computed the stripped
line intending to compare it, and the check compared the raw line instead.

Tests

The new test was written first and failed against 0.2.1 with assert 2 == 1.
120 → 122 tests passing, on Python 3.10–3.13 and both Linux and macOS.

Note on the tag

v0.2.2 is SSH-signed and GitHub reports it verified. Verifying it locally needs
gpg.ssh.allowedSignersFile configured — GitHub is the authority here, and it says valid.