ci: raise the commit body line limit to 100 characters

[otavio]

What

Raises the Check Line Length limit in Commit Message Check from 80 to 100
characters. The subject limit is unchanged at 80.

Why

The GHSA-c5cf-fr53-8wq4 commit failed the check on master
(run 30293820299),
with seven body lines wrapped at 81-82 characters.

The 80-character body limit sat in a dead zone. git log indents bodies by four
spaces, so an 80-column body already renders at 84 and wraps in a standard
terminal — the limit was neither the conventional 72 (chosen so 72+4 fits) nor
wide enough to be permissive. It was also too narrow to hold a long URL or an
advisory summary, and the body pattern has no exemption for unwrappable content,
unlike the title pattern which exempts Merge pull request.

The subject stays at 80 because GitHub truncates commit and pull request titles
well before that, so widening it would hide text rather than help.

Changes

• .github/workflows/commit.yml: Check Line Length pattern {0,80} ->
  {0,100}, with the error message updated to match.

The companion change to the commit skill, which documents the same limit, is in
shellhub-io/claude. Without it the skill that writes commit messages and the
check that validates them would disagree.

Testing

Verified the old and new patterns against the actual GHSA commit body and
synthetic inputs, using re.fullmatch to match JavaScript $ semantics (the
pattern uses only [^\n] classes, no dot, so the engines agree):

Input	80	100
GHSA commit body	FAIL	PASS
body line of 99	-	PASS
body line of 100	-	PASS
body line of 101	-	FAIL

The boundary is exact and the previously failing commit now passes.

Not addressed

Raising the limit does not touch three structural gaps found while investigating,
each of which would have let this failure happen at any limit:

• The check runs on push to master, where a failure is unactionable — the
  commit is already merged and can only be fixed by rewriting history.
• Advisory merges bypass the check entirely. The GHSA private fork has Actions
  disabled, so its PR reported no checks and the commit was first linted only
  after landing on public master.
• There is no local enforcement (no hook, no commitlint config), so authors
  discover violations in CI, and the error names no specific line.

Replacing the six regex steps with commitlint would address all three with one
config shared by CI and a commit-msg hook. Out of scope here.

[github-actions]

Claude finished @otavio's task in 54s —— View job

---

Code Review Complete

Reviewed 1 file across code quality, security, testing, language patterns, and architecture — no new issues found. The code looks good as-is.

The change is a clean, single-purpose adjustment: the Check Line Length body pattern goes from {0,80} to {0,100} with the error message updated to match. The regex stays correct — ^[^\n]+(\n[^\n]{0,100})*$ leaves the subject line unbounded and caps each body line at 100 — the s flag remains inert (no . in the pattern), and the separate title-length checks are correctly left at 80. The PR description's boundary testing and rationale are sound.

---

To request another review round, comment /review.