chore(journey-client): serve a published revision by id

[stewarthsoj]

Summary

Regenerates @epilot/journey-client from journey-config spec 1.6.0, so the runtime can ask for a specific published revision.

The apps/journey-app-v3 pins a save-and-continue session to the revision it started on and refetches with that revision_id on resume.

What changed

• clients/journey-client regenerated: getJourney takes an optional revision_id query parameter, and its 200 response gains revision_id (a new JourneyServedRevision schema in the response allOf).
• 0.7.0 → 0.8.0 (minor — one parameter and one response field added, nothing changed), CHANGELOG entry and a changeset for the aggregate @epilot/sdk minor.
• packages/epilot-sdk-v2 regenerated for the journey API (types, compact definition, docs). Only journey files changed this run.
• A test asserting getJourney carries the revision_id parameter.

Test plan

• openapi (local spec) → typegen → typescript → bundle-definition clean; info.version 1.6.0, getJourney parameters id, version, revision_id, source, orgId, prod server URL preserved.
• vitest green in the client (4 tests, incl. the new parameter assertion); pnpm lint (biome) clean across 524 files.
• getJourneyV2 verified unchanged — no revision_id parameter, no revision_id in its response — so config-engine, Configuration Hub and blueprint-manifest-api are unaffected.
• CI green — blocked on the journey-api prod deploy described above.
• Release 0.8.0 and call getJourney({ id, revision_id }) from the builder against dev for a typed response — same gate.

[stewarthsoj]

Superseded by #498, which carries everything from this PR plus revision_name.

Both regenerate @epilot/journey-client from journey-config 1.6.0. #498 also picks up the revision_name field on JourneyRevisionRequest (ER-5416, journey-api !579), which landed after this branch was cut — the journey builder sends it today and it has been untyped until now.

Carried over from here into #498:

• the 0.7.0 → 0.8.0 bump and the CHANGELOG entry (the client version is bumped by hand; the auto-release job only covers @epilot/sdk and @epilot/cli)
• the test asserting getJourney carries revision_id
• the epilot-sdk-v2 journey regeneration
• prod-only servers — which this PR had right: the published spec declares only journey-config.sls.epilot.io, and CI regenerates from that URL, so any extra entry is stripped on every run

The blocker noted in this PR's test plan is now cleared: journey-api is deployed to prod and docs.api.epilot.io/journey-config.yaml serves 1.6.0, so #498's CI generates from the published spec and passes.

Closing to avoid two changesets and two conflicting 0.8.0 CHANGELOG entries for the same release.

---

Generated by Claude Code