fix(Stepper): define the public context boundary and deprecate useStepperContext - #6074

Decision

useStepperContext and StepperContextValue are not a supported extension point. Three things settled it:

1. The hook returns nothing the caller lacks. A Stepper builds its context entirely from props the caller passed it — activeStep, orientation, density, indicatorPosition, onStepClick. The only fields genuinely new to it were previousActiveStep and registerStep, which are exactly the private coordination.
2. Custom step composition cannot work through it. The connector fill is choreographed inside Step, so a hand-rolled step reading the context still cannot draw a correct track. The export advertised a capability it could not fulfill.
3. No consumers. Nothing in Storybook, the CLI showcase blocks, docs, or tests calls it. The StepperCustomContent block already threads active from its own state — the idiomatic pattern.

Custom composition is supported through <Step> and its children, indicator, and endContent slots.

Approach

Follows the doctrine already stated in Typeahead/busyIndicatorLane.tsx: an @internal tag is a note to a reader, not a boundary. The seam is closed by module boundary instead.

• StepperContext.ts splits the shape. Public StepperContextValue keeps the six safe reads; StepperCoordination extends it with previousActiveStep and registerStep. One object on the wire — the split governs which declaration a consumer can reach, not a second allocation per render.
• StepperCoordination and useStepperCoordination are never re-exported from the barrel.
• useStepperContext and StepperContextValue stay exported and @deprecated, so removal lands at an explicit major rather than in a patch.

Acceptance criteria

Testing

Stepper.public.test.ts follows the existing *.public.test.ts precedent: expectTypeOf locks the private fields off both the public type and the hook's return, asserts the deprecated names are still exported, and asserts the barrel's code never references the internal names.

The guard was verified to bite, not assumed: re-widening StepperContextValue with registerStep made exactly the two matching assertions fail typecheck, while the previousActiveStep ones correctly stayed silent.

One caveat documented in the file header — these assertions are enforced by pnpm -F @astryxdesign/core typecheck, not by the test run, and a failure surfaces as the cryptic TS2554: Expected 2 arguments, but got 1.

• pnpm -F @astryxdesign/core typecheck — clean
• Core suite — 9009 tests / 308 files passing
• pnpm check:repo — green
• astryx component Stepper --dense renders the new guidance

Notes for review

No runtime behavior changes — this is a type-surface and documentation change. The one non-type edit is Stepper.tsx annotating its provider value with the wider type, and Step.tsx switching to useStepperCoordination.

It should fixes #6060