Fix accuracy defects from the review follow-up batch

[heznpc]

The lower-severity half of the same adversarial review as #74. None of these crashes or claims a false success, but each reports something that is not quite true. All were reproduced before being fixed.

Login item names: comma ambiguity

osascript serializes a list as ", "-joined text, so an item named Backup, Inc. is byte-identical to two items Backup and Inc.. Two consequences, both confirmed:

• That item could never be matched → permanently unremovable through this tool.
• With both Foo and Foo, Bar present, removing Foo succeeded but the post-delete recheck still matched the Foo fragment of the survivor → reported failed after a successful removal.

Names are now read one per line (text item delimiters → linefeed), which cannot collide since names carrying tab/newline are rejected upstream.

lsof escapes beyond \x20

lsof escapes every byte it deems unprintable. #73 decoded only \x20, so a tab arrived as a literal ev\x09il and a non-ASCII name as a run of \xNN. Both the awk (network_watch.sh) and JXA (scanner_helper.jxa.js) decoders now handle whole runs — verified that \xed\x95\x9c\xea\xb8\x80 reassembles to 한글 in both engines rather than becoming per-byte mojibake. Control bytes become a space, since they would break the TSV the protocol rides on.

Pinned Homebrew packages were silently dropped

brew appends [pinned at X] for a pinned formula or cask; the regex anchored the latest version to end-of-line, so those lines returned null and the row disappeared. The collector's own wc -l still counted them, so the displayed "N개 업데이트" total disagreed with the rows shown, and a pinned package's available update was invisible. Rows now survive and carry pinned, surfaced in the UI. A pytest guard drives the real regex through JavaScriptCore against all five real brew output shapes.

SpaceGoalSelection

• Determinism: the doc comment promised the same selection regardless of scan order, but label falls back to kind, so two same-size rows of one kind tied completely and the result depended on emit order. Path breaks the remaining tie.
• Float boundary: 2.4 + 0.3 + 0.3 is exactly 3.0 in decimal but accumulates to 2.9999999999999996, so the greedy walked past the set that met the goal, took an extra item, and then labelled the result short of the goal it had reached. (I searched for a genuine case rather than trusting the reviewer's example, which did not actually reproduce.)
• Non-finite sizes are clamped at the parse boundary, where they used to poison every sum and trip a ClosedRange precondition.

Concurrency guards

Login item removal and the observation window now respect isBusy in both directions. Removal could previously start a second concurrent ScanPipeline over the same scan_result.json/report files during a scan — and since that run isn't held in scanTask, 검사 취소 could not stop it. Conversely a scan started under an observation landed in that observation's own results (the scanner's du/lsof as top "real CPU use", VirusTotal lookups as "new connections").

Mothball reported inspection failures as "nothing to archive"

It used scan() instead of scanReport(), discarding failures — and MothballCore's own API comment warns that this exact thing makes "found but could not inspect" indistinguishable from "nothing found". The page now distinguishes them.

Test plan

• pytest tests/ — 369 passed
• swift test — 168 passed
• release_smoke.py --check-only — ok
• Every new test proven against the pre-fix code first. One of them (the float-boundary case) initially had no teeth — my first fixture passed against the old code — so I searched for a combination that genuinely reproduces and replaced it rather than keeping a test that proved nothing.
• Real rescan on this machine: all 59 devtool rows carry pinned, and no escaped process names remain in the network section.

Follows #74.

🤖 Generated with Claude Code