chore(deps): Update xstate to v5.32.4

[X-Guardian]

Description

Bumps xstate from 4.38.3 to 5.32.4 (latest) in @cdktn/cli-core, the only package that declares it.

This is a major version bump (4.x → 5.x) and required migrating the deploy state machine, its consumer, and its tests to the reworked v5 API.

State machine (deploy-machine.ts)

• createMachine<Ctx, Evt, State>(…) → setup({ types, actors }).createMachine(…). The generic-parameter form was replaced by the setup() builder with a types block. The predictableActionArguments flag was dropped (predictable ordering is the default in v5) and services became actors.
• Invoked callback service → fromCallback. The v4 (context, event) => (send, onReceive) => {…} factory became fromCallback(({ sendBack, receive, input }) => …). Since v5 invoked actors receive input rather than the triggering event, the spawn config now flows in through invoke.input. The actor is built by makeTerraformPtyService(spawn) so tests can inject a mock pty.
• send(…, { to }) → sendTo(…); assign<Ctx, Evt> → assign. Action creators were split and the assign implementation signature changed to a single argument.
• raise(…) → sendTo(({ self }) => self, …). The two internally re-emitted events (EXITED on a missing variable, and the OVERRIDE_REJECTED_EXTERNALLY re-label of an external discard) are sent to self rather than raised. Raised events are internal micro-steps and do not surface through the inspection API, so the consumer would otherwise stop observing them.
• Exit code as final-state output. The terraform exit code is captured into context on the EXITED transitions and surfaced through the machine's root output, so consumers read it off the settled snapshot rather than scraping it from an event. This also puts the previously-unused DeployContext.exitCode field to work.
• Named helper types DeploySnapshot (SnapshotFrom<typeof deployMachine>) and DeployActor (ActorRefFrom<typeof deployMachine>) are exported for the consumer.

Consumer (terraform-cli.ts)

This needed the most care, because v5 snapshots no longer expose the triggering event (state.event):

• Transitions come from the actor's own service.subscribe(…), which yields a fully-typed snapshot for the root actor only — replacing service.onTransition(…). Because the factory starts the actor and sends START before we subscribe, the current snapshot is processed once immediately after subscribing so the initial idle → running transition is not missed.
• Events come from the inspect callback (the only source that still carries the triggering event), replacing service.onEvent(…). The root actor is identified by actorRef.sessionId === rootId — self-contained within the inspection event, so it works even while inspection fires during startup before the service binding is initialized. Events are narrowed through the existing isDeployEvent guard.
• interpret(…) → createActor(…, { inspect }). The actor is started explicitly before events are sent.
• waitFor is imported from xstate and its predicate uses snapshot.status === "done"; the exit code is read from snapshot.output; service.send("X") calls became service.send({ type: "X" }).

Tests

• deploy-machine.test.ts was migrated to match: interpret().onTransition → createActor().subscribe, withConfig({ services }) → provide({ actors }), machine.transition → getNextSnapshot, and the state.event assertions rebuilt on the inspection API.
• A deploy suite was added to terraform-cli.test.ts covering the previously-untested deploy()/handleService path: running is reported even when the process exits immediately (the subscribe-ordering fix), a zero exit resolves without cancellation, and a non-zero exit rejects with the exit code (the final-state-output path).

tsc --noEmit passes cleanly on the package, and all 28 tests across deploy-machine.test.ts and terraform-cli.test.ts pass.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes

[sakul-learning]

I validated a non-blocking ordering regression in TerraformCli.handleService(): createAndStartDeployService() starts the XState actor and sends START before handleService() attaches service.subscribe(). A silent process that exits immediately can therefore miss the running callback ([] rather than ["running"]); ordinary Terraform output produces a later snapshot that reports it, so I would not block this XState update on that behavior.

What the repro shows

createAndStartDeployService() starts the actor and sends START before handleService() subscribes to snapshots. A silent process that exits immediately therefore never reports the initial running callback:

jest.mocked(spawnInteractive).mockReturnValue({
  actions: {
    write: jest.fn(),
    writeLine: jest.fn(),
    stop: jest.fn(),
  },
  exitCode: Promise.resolve(0),
});

const states: string[] = [];
await cli.deploy({}, (state) => states.push(state.type));

expect(states).toEqual(["running"]);

On this PR head, the assertion fails with received: [].

This is technically an observable behavior regression from v4, but normal Terraform apply/destroy invocations emit stdout/stderr. Those events produce a later snapshot while the machine is still in running.processing; because previousState is still idle, that later snapshot triggers the running callback and masks the missed initial transition. I also verified that output emitted during actor startup is observed, and that an immediate non-zero exit is still propagated correctly.

So I see this as a non-blocking lifecycle hardening opportunity, rather than evidence of a current customer-facing failure. The practical difference for a real Terraform run is that running is reported on its first output instead of immediately on entry. The silent/immediate process is useful for exposing the ordering, but is not representative enough to justify blocking the dependency update by itself.

Minimal fix validated locally

Processing the actor's current snapshot once after subscribing restores the initial callback without changing the factory API:

const handleSnapshot = (
  snapshot: ReturnType<typeof service.getSnapshot>,
) => {
  // existing transition handling
};

service.subscribe(handleSnapshot);

// The actor was already started by createService, so consume the
// snapshot whose transition may have preceded the subscription.
handleSnapshot(service.getSnapshot());

I pushed the TDD sequence as two commits:

1. RED — repro test: sakul-learning@8bcd827
2. GREEN — minimal fix: sakul-learning@e4f72c3

Branch: https://github.com/sakul-learning/cdk-terrain/tree/review/pr-333-xstate-running-repro

Validation:

• RED commit: focused suite fails exactly one test, reports running before a silent process exits (1 failed, 5 passed).
• GREEN commit: focused suite passes (6/6).
• Full @cdktn/cli-core suite with the fix: 163 passed; 30 existing dist-dependent tests skipped.
• Prettier and git diff --check: pass.

Given the realistic execution path and green existing CI, this is a suggestion rather than a requested change.

[so0k]

Up to you if you want to address the non-block ordering concern (which may not be a real failure mode) - still need to rebase for conflict resolution