gitleaks:allow is not in the common directive list, so a strip removes a secret-scanner suppression

[P4suta]

Third one from the same run as #26 and #27.

//gitleaks:allow is the inline suppression gitleaks reads, and it is not in the
common list in directive_name, which already carries the neighbours it sits
beside in practice — nolint, noqa, eslint, ts-ignore, istanbul ignore,
c8 ignore, coverage:.

So a strip removes it:

// before
const copiedKey = "0123456789abcdef" //gitleaks:allow

// after
const copiedKey = "0123456789abcdef"

Why it is worth a line of its own

The removal is silent and the failure arrives somewhere else. In the repository
this came from, the next gitleaks dir . reported the constant as a
generic-api-key — a test fixture whose whole job is to be shaped like a
workspace key. The suppression was the only thing saying so, and nothing tied
the two together after it was gone.

It is also the one class of directive whose removal can cost something rather
than just annoy: a suppression that disappears turns a quiet gate red, and the
usual repair is somebody adding the finding to an allowlist file instead —
which is worse, because a path-keyed allowlist goes stale where an inline
marker cannot.

Suggested fix

Add gitleaks: to common, next to nolint and noqa. The marker is
//gitleaks:allow today; matching the gitleaks: prefix leaves room for the
others without guessing at them.

Nearby, and for a maintainer to judge rather than a request: codespell:ignore,
cspell:disable, vale off, lint:ignore and deepsource-ignore are the same
shape. I have not hit those, so I am not asking for them.

Versions

ocomment 0.1.0, macOS 27.