fix(commerce-elastic-path): declare every /server export in server.d.ts

[field123]

dist/server.d.ts is not derived from src/server.ts — it is a template string inside build-server.mjs, hand-mirrored from the source, and it had drifted. 17 of the entry's 105 exports shipped working JavaScript with no type declaration, so importing any of them failed a consumer's typecheck while the runtime worked fine.

The example app imports createManualAdapter, handleResumePayment and handleAbandonPayment from /server, so bumping it to 0.6.0 would have broken next build on three counts. Its tsconfig.json sets strict: true and next.config.js sets no typescript.ignoreBuildErrors.

Caught by building 0.6.0 locally before publishing. 0.6.0 is not yet on npm.

Scope

Declares all 105 exports rather than only this release's additions. An earlier revision deferred the six that predate 0.6.0 on the grounds that they are equally broken in published 0.5.3 and so not a regression — but two of them are exactly what the example app needs, and the SSR cart-seed helpers (seedCartFallback, EP_CART_CACHE_KEY, epCartCacheKey, EpCartCacheKey) are documented in src/server.ts for use in a consumer's root layout, so they are public API too. "Not a regression" is not the same as "usable".

No CHANGELOG entry: the defect existed only inside the unpublished release branch, so it never reached a consumer and has nothing to announce.

Verified

Packed the built tarball and typechecked a consumer importing every export, each value as a value and each type as a type, under strict + isolatedModules:

• with this change: tsc exits 0 across all 105
• without it: TS2305 on the 17 undeclared names
• zero TS1361/TS2693, which is what an export {}/export type {} inversion would produce

Known, not addressed

CustomAttributeAllowList is declared in the template but is not an export of src/server.ts. It predates this change, it is type-only, and it resolves — but it means the declared surface is one name wider than the source. Removing it would narrow a type surface already shipped in 0.5.3, so it is left alone.

Nothing guards against a fourth drift: no test asserts template/source parity, and publint runs only from prepublishOnly, never in CI. Generating the declaration from src/server.ts, or a parity unit test, would close the failure mode — both belong in their own change rather than a release path.

Refs #557, #559