The studio can look at your change but cannot ship it #225

Pushed successfully.

The studio's Decide card previously only ever came from the crew's own asks pipeline (decisionsFor, agent pulls only), so a change a person opened through the studio's own editor never got one — the only way to ship it was to leave for dev's pull page.

studioPull (src/web/studio/change.ts) now builds the same kind of Decide card for a person's own open pull when no crew decision already covers it and the viewer can write here:

• Green (or a repository that doesn't require checks) offers Ship, through the exact same /ship route and decisionActions the crew's cards already use.
• A conflict reuses the existing bring-up-to-date wording and button verbatim (conflictWords, change.ts:37-44), regardless of who opened the change.
• A check that hasn't gone green yet (and the repo requires it) says so in the studio's own words instead of offering a button that would be refused.

Same-origin and the write check are enforced both in rendering (canWrite) and, unchanged, in shipSubmit itself — nothing new decides what may land. The crew's own Decide card is untouched: when decisionsFor already has an answer, that's what renders.

Left out: the front door's asks panel (issue #208) still only lists the crew's changes — this only reaches the change's own page, per the issue's scope, so as not to preempt #208's design there.

Tests added in test/studio.test.ts (new describe block "a person's own change ships from its own studio page"): a green change a person opened themselves offers Ship to a writer and nothing to a reader; shipping it lands the pull and the page reads shipped; a conflicted change offers the bring-up-to-date wording instead of a Ship that would be refused. Full check suite passes except for pre-existing git-auth failures in this sandbox (confirmed identical on unmodified main, unrelated to this change).

Closes #211