A change that cannot land says so, instead of reading green #127

A change's own studio page now asks git once, whether it still merges into its base, and says so before anyone presses anything.

• studioPull calls pullStatus (the same helper dev's pull page already uses) for an open, unmerged pull only — no git call added to lists, the app page's ask cards, or the home.
• When it conflicts, the check-line note is replaced with a sentence naming the base branch and the first few conflicting files (and N more past three), and saying what fixes it.
• The Decide card's button is no longer "Ship" — it posts to the same /ship route, worded "Bring up to date"; shipSubmit already turns a conflict there into the crew bringing the branch up to date (per Atlas's note), so no new write path was added.
• No sixth badge: the word stays whatever the check already decided; only the note and the decision's wording/action change.
• Per the issue's own risk section, the ask cards on the app page and home are left as they read today (by check alone), since there's no cheap (non-git-per-card) source for mergeability yet.

Added test/studio.test.ts: "a change that no longer merges into its base says so, and offers no Ship — a mergeable green pull is unchanged" — builds a real conflicting pull (two branches editing the same line), asserts the conflict sentence, file name, and "Bring up to date" appear with no "Ship", and that an ordinary green pull is unaffected. bun x tsc --noEmit and the full check suite pass except for pre-existing failures (pulls.test.ts, apps.test.ts) caused by this sandbox refusing outbound git push/auth — verified identical on main before my change.

Closes #86