Upload data api three layer refactor

[osama-rizk]

Description of changes

Refactor the internal uploadData API in @aws-amplify/storage to follow the
three-layer architecture (foundation / client / server):

• foundation/ — environment-agnostic core. Contains calculateContentCRC32
  and calculateContentMd5, which now receive a FoundationContext
  ({ amplify, readFile, toBase64 }) via dependency injection instead of
  branching on the runtime.
• client/ — browser + React Native implementations of readFile and
  toBase64 (with .native.ts splits preserved), plus the public
  client-side uploadData API.
• server/ — Node.js implementations and the public server-side
  uploadData API, which injects the request-scoped Amplify instance from
  getAmplifyServerContext.

The uploadData call graph (putObjectJob, getMultipartUploadHandlers,
uploadPartExecutor, loadOrCreateMultipartUpload) now threads
FoundationContext instead of AmplifyClassV6, so the foundation layer is
fully free of environment-discriminating logic.

Public API surface is unchanged. Routing to the correct bundle per
environment is handled via conditional exports in package.json
(browser / import / require), and the existing
aws-amplify/storage/server subpath is preserved for backward compatibility.

Legacy providers/s3/utils/{crc32,md5,readFile}.ts are kept as shims for
deleteObjects until remove is migrated; new code imports from
foundation/utils and client|server/utils instead.

This is the first API migrated to the three-layer pattern; follow-up PRs
will apply the same split to the remaining Storage APIs.

Issue #, if available

N/A — internal refactor, no customer-facing behavior change.

Description of how you validated changes

• Existing unit tests for uploadData updated to pass FoundationContext
  instead of Amplify; all continue to pass.
• Added direct unit tests for the new foundation/utils/*,
  client/utils/*, and server/utils/* modules. New code has 100%
  statement/function/line coverage.
• aws-amplify Jest config now runs two projects so the umbrella
  package's exports are verified under both resolution paths:
  • node project (pinned customExportConditions: ['node']) — existing
    tests, asserts the SSR surface of @aws-amplify/storage in
    exports.test.ts.
  • browser project (jsdom defaults) — new exports.browser.test.ts
    asserts the full client-side surface (uploadData, downloadData,
    remove, list, getProperties, copy, getUrl, isCancelError,
    StorageError, DEFAULT_PART_SIZE).
  • babel-jest with @babel/preset-env (modules: 'commonjs') is used
    to transform the .mjs ESM bundle emitted by @aws-amplify/storage
    so Jest can load it under the browser condition; ts-jest continues to
    handle .ts/.js.
• predictions Jest config no longer pins the node export condition.
  It provides a global moduleNameMapper stub for @aws-amplify/storage
  (predictions only consumes getUrl), which removes the need for a
  resolution pin. Existing per-test jest.mock(...) overrides still work.
• yarn test passes for the storage, aws-amplify, and predictions
  packages. Package-level coverage thresholds respected.

Checklist

• PR description included
• yarn test passes
• Unit Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)

Checklist for repo maintainers

• Verify E2E tests for existing workflows are working as expected or add E2E tests for newly added workflows
• New source file paths included in this PR have been added to CODEOWNERS, if appropriate

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

🦋 Changeset detected

Latest commit: 46eacc1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@aws-amplify/storage	Minor
aws-amplify	Minor
@aws-amplify/predictions	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR