Build unavailable states: unreachable mentions and links from a previous HQ #111

Part of #78. Fixes two should-fix findings from #78's Spec review about unavailable states (#78 Settled constraints: Unavailable HQ, and The link is thread metadata).

Problems

1. Unreachable reported as unknown. When HQ can't be reached, BuildWorkItems.mentions leaves an unresolved number out of its result, the same as a number Build doesn't know. Mobile's ThreadBuildItemSheet.tsx then says "Build has no item #n you can see" for a written Build URL, when it should say Build couldn't be reached.
2. A link from a previous HQ still opens a card. When the project's HQ origin changes, view marks the header segment unavailable. But the segment's hover card (web) and the sheet (mobile) still call card({ itemId }), and card reads that id on the current HQ without checking the link's origin. Show the thread's Build Spec or Ticket in the header, with cards and live chat links #78 says such a link shows as unavailable and is never resolved against another HQ.

Scope

• mentions tells clients when it couldn't reach Build, apart from numbers Build doesn't know. Mobile's sheet shows the existing "couldn't be reached" state for it. Web keeps its current fallback (the text as written).
• card for a thread whose linked item is on a different HQ origin from the project's returns the unavailable state instead of reading the current HQ. Mention cards keep reading the project's HQ.
• Contract changes stay readable by older clients and servers.

Classification

Non-ui, with a one-line mobile state change.

Acceptance

Server tests with the fake HQ: an unreachable HQ makes mentions report unavailability rather than an empty result, and a link whose origin differs from the project's gets no card read from the current HQ.