fix(routing): route on basename length too, not just total arcname length

[Jarrod S Doucette (jdoucett)]

Summary

• Two production drops (repository_X1D_2_spectral-standoff, repository_X1J_1_visual-injury, 2026-07-18/19) hit indexed htar -L's silent member-omission again — caught by ship_object's stdout scan (no data lost), but not by choose_transport's existing HTAR_ARCNAME_LEN_LIMIT, since both had short total relpaths (166, 124 chars) with an overlong final basename (102, 110 chars). ustar's 100-byte "name" field holds only the final path component, so this is a distinct constraint from the total-path ceiling PR fix(routing): route + detect htar's silent member-drop modes #29 fixed.
• Reproduced live on Negishi (synthetic files, short total path, varying basename length): 99-char basenames archived cleanly, 100-char basenames were dropped every time, same boundary at any nesting depth.
• Added HTAR_BASENAME_LEN_LIMIT = 95 (5-char margin under the confirmed 100-char cutoff) and route to htar_large when any member's basename is at/over it, alongside the existing size/arcname checks in choose_transport().

Test plan

• New unit tests: short-path/long-basename routes to htar_large, basename boundary test, long-basename-among-short-ones
• Fixed a pre-existing arcname-boundary test that unintentionally regressed (its no-slash test string was also its own basename)
• Verified against the two actual production arcnames — both now route to htar_large
• Full suite green (395 passed)