fix(review): suppress findings inside Markdown fenced code blocks (#329)

[ajianaz]

Summary

Fixes the root cause of #329: Markdown fenced code blocks (documentation examples) were treated like executable code, producing false positives — e.g. a git push inside a ```bash block flagged as SQL injection.

Approach

Issue #329 offered three options (skip code blocks / reduce severity / language-hint matching). Skipping code blocks entirely subsumes language-hint matching for the common case and is the cleanest, so that's what this implements.

New module engine::markdown:

• is_markdown(path) — detects .md / .mdx / .markdown
• lines_inside_code_blocks(chunk) — returns the set of new-file line numbers inside ``` / ~~~ fences. Tracks fence state across full hunk context (Add + Context lines, skipping Removed lines), so it works even when only the body of a code block was edited (the opening fence is often pre-existing context).

New filter apply_markdown_code_block_filter() in review.rs:

• Applied at the single choke point where all findings (security/secrets/rules scanners + LLM) are unified as Vec<ReviewIssue> — right next to apply_ignore_rules, in both the success path and the LLM-failure fallback path.
• Drops findings whose file is markdown and whose line falls inside a code block.
• Safe defaults: findings with no resolvable line number are kept; non-markdown files are unaffected. Fast-paths out when the diff has no markdown code blocks.

Why this design

• One filter covers all sources. Deterministic findings get merged into response.issues after the LLM call, so filtering at the unified ReviewIssue stage catches regex-scanner and LLM false positives in one place.
• Hunk context is already available (DiffLineType::Context lines are parsed), so fence tracking is reliable without extra file I/O.
• Skips Removed lines so deletions can't corrupt fence state (e.g. a removed closing fence won't leave the tracker stuck "inside").

Scope

This addresses the systematic markdown code-block root cause (#329 item 1). The issue's other two observations (CHANGELOG future-date timezone; Cargo.lock format) are not regex-scanner artifacts — they come from LLM/rule paths and are noted for separate handling.

Testing

• 11 new tests: 7 unit (fence detection: backtick/tilde fences, context-line fences, removed-line resilience, indented markers, empty) + 4 integration (the exact False positive patterns: markdown code blocks flagged as real code (SQL injection, security) #329 scenario, finding-outside-block kept, non-markdown unaffected, no-line-number kept).
• All 648 tests pass (626 unit + 16 CLI + 6 config).
• Clippy clean, fmt clean, cargo audit clean.

Refs #329