fix(history): accept place ids when restoring a session

[tkgstrator]

Hotfix — production is broken for 17 of the 43 cases. Branched off master rather than
develop, which is holding unreviewed work.

What happens

Opening a case that has investigable places throws 「レスポンスの形が想定と違うよ〜」 before
the player can ask anything. Reported from a real play on 十七回忌の客.

The interrogation screen reads GET /api/sessions/:id/history the moment it mounts.
sessionHistorySchema.histories[].characterId allowed a uuid or the literal victim —
but places carry an author-written local id (choba, garden), so the response fails to
parse and the screen goes down with it. Two sessions on production show it exactly: zero
messages, zero model calls. It never got past the first read.

The fix

One union, widened to the three kinds of subject that exist, reusing placeIdSchema from
db/scenario-definition.ts so there is one definition rather than a copy.

The comment above that union already described this failure — it was written when the body
became a second kind of subject. Adding a third did not reach it. The comment now says so,
and there are tests for all three plus a rejection.

Verification

The two production responses that were failing were replayed against the fixed schema and
both parse.

Test plan

• bun run typecheck — clean
• bun run lint — no errors
• bun run test — 725 pass / 0 fail, including four new cases for the subject id union
• the actual failing production payloads parse after the change
• after deploy: open 十七回忌の客 and confirm the screen loads

After this

Needs back-merging into develop so the fix is not lost on the next release.