chore(ci): scan only commit subjects for version-bump classification

[artyomsv]

Summary

Fixes the false-positive minor bump on PR #35 (docs restructure) that shipped v1.13.0 with no user-visible changes.

The release pipeline was scanning both subject AND body of every commit since the last tag, hoping to catch type lines preserved in squash bodies when the subject was branch-name-derived. That heuristic produced this false positive: the #35 PR description contained the literal back-tick-wrapped reference

This PR is independent of #34 (`feat(tui): add Stop daemon action`).

…and the regex \bfeat[(:/] matched the substring feat( inside the backticks just as readily as it would have matched a real feat(tui): commit. The release job classified the PR as minor and shipped v1.13.0 with nothing user-facing in it.

Fix

What	Before	After
Type classification (feat/fix/perf/bang)	scans %s%n%b (subject + body)	scans %s (subject only) — the merger sets the squash subject explicitly and it IS the authoritative classification
BREAKING CHANGE detection	matched anywhere in subject+body via BREAKING CHANGE	matches ^BREAKING[ -]CHANGE: in body anchored to line start with trailing colon — the Conventional Commits footer form. Prose mentions like "this is not a BREAKING CHANGE" no longer match.
Branch-name fallback (feat/foo-bar)	covered via body scan	still covered — the existing [(:/] regex on subjects accepts feat/foo-bar form natively

Diff is ~30 lines, all in .github/workflows/release.yml.

Why this never bit before

The body-scan was a defense-in-depth measure for branch-name-derived squash subjects. In practice, every merge in this repo's history has had a properly conventional subject set by the merger, so the body scan never had to do its intended job — it just sat there waiting to false-positive. PR #35 was the first PR whose description text contained a conventional-commit-style reference to another PR, and that's when the bug surfaced.

Self-test

Smoke-tested the new regex on the prose vs. footer distinction:

$ echo "BREAKING CHANGE: yes" | grep -qE '^BREAKING[ -]CHANGE:'
→ match (correct — real footer)

$ echo "no BREAKING CHANGE here" | grep -qE '^BREAKING[ -]CHANGE:'
→ no match (correct — prose mention)

$ echo "feat(api): add foo" | grep -qiE '\bfeat[(:/]'
→ match (correct — real subject)

$ echo "ref to feat(api)" | grep -qiE '\bfeat[(:/]'
→ matches the regex but the body is no longer scanned for feat —
  irrelevant to the bump path now

Why this PR doesn't bump

The PR is committed as chore(ci):, which falls through to the "skip release" branch in the workflow itself. No v1.14.1 release will be cut by merging this; the next user-visible feature PR will bump as normal.

Test plan

• Inspected the PR docs: restructure into navigable docs/ tree and add MCP user guide #35 squash body to confirm the matching string (`feat(tui)` inside backticks)
• Verified the new ^BREAKING[ -]CHANGE: anchor matches the Conventional Commits footer form but not casual prose
• Confirmed chore(ci): does not match the bump regexes — this PR's own merge will skip the release job (no v1.14.1 will ship)
• Diff is small and reviewable (~30 lines, single file)