fix(p9): ignore visible Markdown table alignment - #681

[SkillSpector Review]

Hi @efegokdemir, thank you for tackling the P9 table false positive with a fail-closed table check!

Value and readiness: The change removes the #676 false positive. In a proven outer-pipe GFM table, aligned ASCII cell padding no longer raises P9. Unicode padding and pipe rows without a delimiter row are still reported. However, the exemption has no width limit and does not check that the alignment is consistent. A valid table can therefore push content off-screen without a finding, and that is exactly what P9 exists to catch. The exemption needs one more constraint before merge.

Material findings

1. [Blocker] src/skillspector/nodes/analyzers/whitespace_padding.py:322-328: any run of 80 or more ASCII spaces that ends at a | inside a proven table is skipped, however long it is. For example:

   | A | B |
   |---|---|
   | notes<2000 spaces>| <hidden instruction> |
   

   main reports this as a horizontal P9 finding. On this head nothing reports it. The horizontal run is exempt. The block signal needs more than 2048 bytes, and the ratio signal needs a file larger than 4096 bytes. In a raw view (editor, terminal, GitHub diff), the second cell starts about 2000 columns to the right, off-screen. The PR description says off-screen layouts remain detectable, and #676 asks for that, but this one is not detected.

   Please exempt a run only when it matches the table's own visible alignment, i.e. the | that ends the run is in the same column as the corresponding | of the delimiter row. A delimiter cell that wide needs that many dashes, and 512 or more repeated dashes already trigger the P9 repetition signal, so this also limits the exemption. Please add a test where a valid table row has a long run before an inner | that does not line up with the delimiter row, and assert a horizontal finding.

2. [Non-blocking] tests/nodes/analyzers/test_whitespace_padding.py:213-233: no test covers a long ASCII run inside a cell that is followed by more text in the same cell, rather than by a |. The code keeps reporting it (line[k] == "|"), and a test would lock that in.

PIC tradeoffs: How wide a "visible" table may get. With the delimiter-row alignment check, a table with several columns, each under 512 dashes, can still place a later cell several hundred columns to the right without a P9 finding. The dash row then runs off-screen too, so the width is visible but not the content. If that is too permissive, also cap the end column of the exempt run (for example a few multiples of HORIZONTAL_RUN_CHARS). The cost is that very wide legitimate tables would keep being reported.

Verification and gaps:

• I traced _markdown_table_lines and the new exemption at head 5bd6418 on these inputs:
  • the issue example: no finding;
  • a U+3000 run: still reported;
  • a pipe row without a delimiter row: still reported;
  • the off-screen example above: not reported.
• For a 2000-space run in a small file, I also checked that the block, ratio and repetition signals do not fire.
• Fenced code is still skipped before the table logic. The table scan is a single linear pass, so resource bounds do not change.
• _markdown_table_cells splits on every |, including escaped pipes and pipes inside code spans. That can only stop a legitimate table from being recognized, which keeps today's behavior, so it is acceptable.
• Overlap: #624 also edits whitespace_padding.py (dedup by source occurrence). That file auto-merges cleanly between #624 and this head. The only conflict is #624's existing conflict with main in static_runner.py, which is unrelated to this PR. This head merges cleanly with current main.
• CI: all 6 checks are green. Per policy, I did not run the tests locally.

Decision: Changes Requested (reviewed head 5bd64183cfab1f9a9d9def60d1c532ccdf1481e3)