Hub: wi-cli refused by cross-cwd identity guard - a shared CLI has no session and cwd is not its identity

SHIPPED hub 2.47.2, commit 55343d1. Recorded after the fact - the commit message cited 'MSG-320' before a WI existed, and MSG-320 was then minted for the gitpush hunk-gate bug. This WI is the real ref for 55343d1; MSG-320 in that commit message is a dangling label, corrected here rather than rewritten in history. DEFECT: wi registers as 'wi-cli' from whatever directory the invoking agent is in, so two agents running wi from two projects trip the cross-cwd identity guard by construction. The 409 told it to 'pick a distinct name or stop the other session' - meaningless advice for a shared CLI with no session. 6 refusals in 7d. WHY IT WENT UNNOTICED: the wi launcher tolerates register failure (wi_hub_post /register ... || return 0), so notifications kept working and nothing visibly broke - while bwi became the fleet's state of record under MSG-309. FIX: isSharedTool = wi-cli | scrp-* | applog-* skips the cross-cwd guard. Same reasoning that already exempts script senders: no session, no takeover to detect. VERIFIED: direct POST /register for wi-cli from a foreign cwd returns ok:true, roster cwd updates, zero identity-conflict alerts. Before the fix the same call was refused 409. NOT FIXED, separate and larger: 1,180 of 1,333 identity-conflict messages in 7d are the 'informational, NOT blocked' class, which says 'No action needed' by construction. Agent-only fan-out already (Elazar ruling 2026-08-16), so it is not PM noise, but it is ~168 unactionable DMs/day fleet-wide. Not changed unilaterally - Elazar personally ruled on this alert class's recipients.