Re-export IntlShape from the runtime barrel

[brian-smith-tcril]

AI-drafted enhancement request. The text below was drafted by Claude and reviewed by me — the underlying observation and proposal are mine.

Context

@openedx/frontend-base re-exports the runtime pieces of react-intl from its barrel:

export {
  createIntl, defineMessages, FormattedDate, FormattedMessage,
  FormattedNumber, FormattedPlural, FormattedRelativeTime, FormattedTime,
  IntlProvider, useIntl
} from 'react-intl';

but does not re-export the IntlShape type, which react-intl exports alongside useIntl.

Problem

Consumers who need to type an intl parameter (functions that take intl explicitly, tests that assign a modified intl to a typed variable, etc.) have two options today, both awkward:

1. import { IntlShape } from 'react-intl' — pulls a direct react-intl dependency into consumer src/, bypassing the frontend-base abstraction boundary that everything else is going through.
2. Derive it locally: export type IntlShape = ReturnType<typeof useIntl>; — stays inside the boundary, but every downstream app needs the same one-line type util file to reference.

Frontend-app-catalog picked option 2 during its frontend-base port and now has src/utils.ts exporting exactly that, with ~6 consumers importing IntlShape from @src/utils. Same pattern will likely repeat in every ported app.

Proposal

Add IntlShape to the barrel:

export type { IntlShape } from 'react-intl';

The current file is runtime/i18n/index.js, so this would need either a rename to .ts (cleanest) or a co-located .d.ts sibling (less clean, but avoids touching the file's extension). Type-only re-exports have no runtime footprint.

Once landed, downstream apps can drop their local IntlShape = ReturnType<typeof useIntl> shim and import from @openedx/frontend-base alongside useIntl / IntlProvider / etc.

Related

Same abstraction-boundary concern that shows up in frontend-app-catalog's src/utils.ts. Discovered while reviewing test-porting work on the frontend-base branch of that repo.