refactor(setup): extract doctor visual rendering

[codeforester]

Summary

Extract the doctor visual-status rendering helpers from setup_common.sh into a guarded, idempotently sourced module. Update the ownership map and add sourcing coverage.

Validation

• 22 setup-common BATS tests
• bash -n
• ShellCheck
• git diff --check

Fixes #2354

[codeforester]

Automated review finding

docs/setup-common-ownership.md: the PR only updates the two ownership-map rows immediately adjacent to the split (the new setup_doctor_visual.sh row and the row for the functions remaining just above/below it in setup_common.sh), but every row below the split now has stale line ranges - off by roughly the 62 lines removed from setup_common.sh. One row ("1278-1302") now points past the file's new end-of-file entirely (the file is only 1259 lines long post-PR). The new row's own ranges are also slightly off: "setup_doctor_visual.sh 1-62" vs. the actual 66-line file, and "setup_common.sh 790-850" for functions that actually start at line 855.

No test catches this - test_setup_common_ownership_docs.py only checks that documented function names exist somewhere in the combined sources, not that the cited line ranges are accurate. Since this doc's stated purpose is to be an anchor map for locating these functions, a maintainer following it will land on the wrong lines.

Posted via Claude Code

[codeforester]

Follow-up on the previous review comment

The line-range fix itself is good - verified every row below the split point (setup_doctor_visual.sh, and the 5 recomputed setup_common.sh rows) against actual grep -n/wc -l output; all match exactly, including the row that previously pointed past end-of-file.

However, the new test meant to guard against this drifting again doesn't actually work. test_setup_common_ownership_doc_ranges_contain_function_anchors (in 1ccb77ad) is supposed to parse each row and assert its anchor functions fall within the stated range, but its row-parsing regex has a greedy-.* bug that captures the "Target owner" column instead of the "Entry-point anchors" column - every row's parsed anchor set ends up empty, so the test only checks end <= len(lines), a weak sanity check that doesn't verify any anchor's actual position.

Confirmed empirically: edited the doc to set a row's range to a deliberately wrong value (nowhere near the real function locations) and reran the test - it still passed.

Suggest tightening the row-parsing regex to correctly capture just the anchors column (e.g. make the trailing .*? non-greedy and anchor it to stop at the next |), then re-verify the test actually fails on a deliberately wrong range before merging.

(Also noting, not blocking: 3 rows above the split point - 314-410, 414-632, 636-784 - were already stale before this PR and remain so, e.g. setup_base_check_metadata() is documented under 414-632 but actually sits at line 657. Pre-existing, out of scope for this PR.)

Posted via Claude Code