[Varshith-Kali]

Summary

Fixes #901. Two shapes of ordinary, everyday text made
static_patterns_tool_misuse report static_parse_limit, which marks the
file partially inspected and raises an AE1 HIGH finding on the referencing
file, pushing an otherwise clean skill to risk score 25 (CAUTION):

1. A backtick-quoted word inside a shell comment, e.g.
   # Uses the `printf` builtin. in scripts/run.sh.
2. An unmatched apostrophe in Markdown prose after inline code, e.g.
   Run `rm -f build.log` to clean the project's output. in
   references/guide.md.

Root cause

1. _has_shell_command_word_exhaustion treated the backtick inside the
   # comment as a command-substitution candidate. The substitution
   statically reconstructs as a printf invocation, which sets the
   parsed word's limited flag, and that flag maps to
   LedgerReason.STATIC_PARSE_LIMIT. The shell never executes comments,
   so the backticks there are literal text.
2. _markdown_shell_text masks paired inline-code delimiters, but the
   prose-apostrophe retry (word_apostrophes=True, added for fix(analyzer): keep Python and Perl syntax from exhausting the shell parser #778) judged
   the raw line, so the backticks read as shell syntax and the possessive
   in project's was never masked. The bounded shell tokenizer then
   opened a single-quoted span at the apostrophe that never closed,
   exhausting the span bound.

Changes

• In _has_shell_command_word_exhaustion, a candidate whose parse hits
  the printf-reconstruction bound (parsed.limited) inside a #
  comment no longer counts as exhaustion (new _is_comment_candidate
  helper). Unresolved spans and runtime-selected operands keep their
  existing conservative treatment, and the skip applies only to file
  types where # opens a comment (Markdown headings keep their
  deliberate partial result). For host Python source the comment token
  must be proven through _PythonSourceOwnership, so a # inside a
  string literal keeps the conservative behavior.
• The Markdown word_apostrophes prose check now judges the line with
  its line-local paired backtick runs blanked (new
  _blank_line_local_paired_backticks, mirroring the paragraph-scope
  pairing of the inline-code masking). Unpaired or cross-line ticks stay
  visible, keeping the check conservative.

Verification

• Both issue reproducers scanned end to end (--no-llm) before the fix:
  AE1 HIGH, static_parse_limit ledger exception, score 25, status
  partial. After the fix: score 0, SAFE, status complete, zero findings
  and zero ledger exceptions.
• New regression tests in
  tests/nodes/analyzers/test_static_parse_limit_issue_901.py (11
  tests): both reproducers at unit and ledger level, #-in-string
  guards for shell and Python, unpaired-backtick conservatism, the
  pairing helper, and a guard that runtime-selected destructive
  operands in comments keep their conservative partial result.
• Full tests/nodes/analyzers/ suite: 8338 passed, 0 failed.
• Before/after differential on edge cases (commented $(...),
  unclosed backticks, inline code with real expansions, # inside
  quoted strings, the static_parse_limit: a backtick template literal whose first word holds a non-trivial ${...} is read as a possible printf substitution #884 TypeScript template literal, long
  unresolved spans in comments): only the issue's reproducers changed
  behavior; everything else is identical.

Fixes #901.