chore: prep for 2.0.6 release

[ignaciosantise]

This pull request fixes image loading for wallets and networks on React Native by changing how image data is fetched and encoded. The main improvement is replacing the use of response.blob() and FileReader (which are not supported on React Native for binary data) with response.arrayBuffer() and a custom base64 encoder. This ensures images load correctly instead of silently failing and showing placeholders. Comprehensive tests are added to cover the new logic.

React Native image loading fix:

• Updated FetchUtil.fetchImage to use response.arrayBuffer() and a custom dependency-free base64 encoder instead of response.blob() and FileReader, resolving image loading failures on React Native.
• Added a static _arrayBufferToBase64 method to FetchUtil to encode image data without relying on Node or browser globals like Buffer or btoa.

Testing improvements:

• Added tests in FetchUtil.test.ts to verify base64 data URL generation, fallback behaviors, content type defaults, and correct handling of errors and unsupported methods.

Documentation and release notes:

• Added a changeset describing the fix, its motivation, and the affected packages.

[changeset-bot]

🦋 Changeset detected

Latest commit: 8e991af

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

This PR includes changesets to release 9 packages

Name	Type
@reown/appkit-react-native	Patch
@reown/appkit-bitcoin-react-native	Patch
@reown/appkit-coinbase-react-native	Patch
@reown/appkit-common-react-native	Patch
@reown/appkit-core-react-native	Patch
@reown/appkit-ethers-react-native	Patch
@reown/appkit-solana-react-native	Patch
@reown/appkit-ui-react-native	Patch
@reown/appkit-wagmi-react-native	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

[claude]

Claude finished @ignaciosantise's task in 2m 41s —— View job

---

PR Review

• Gather context
• Read changed files
• Spawn breaking changes subagent
• Analyze and post findings

---

No breaking changes detected. The fetchImage signature and return type are unchanged; _arrayBufferToBase64 is private static.

Found 2 issue(s)

Issue 1: Base64 padding branches have zero test coverage

ID: fetchutil-test-padding-coverage-a3f1
File: packages/core/src/__tests__/utils/FetchUtil.test.ts
Severity: MEDIUM
Category: test_coverage

Context:

• Pattern: Both fetchImage test cases that exercise _arrayBufferToBase64 use byte arrays whose length is divisible by 3 ([0x66, 0x6f, 0x6f, 0x62, 0x61, 0x72] = 6 bytes; [1, 2, 3] = 3 bytes). The = and == padding branches at lines 119–121 of FetchUtil.ts are never executed.
• Risk: A regression in the padding logic would go undetected by the test suite; one-pad (len % 3 == 2) and two-pad (len % 3 == 1) cases are both uncovered.
• Impact: Images whose raw byte count is not a multiple of 3 (the vast majority of real PNGs/JPEGs/WebPs) would produce a malformed base64 string that Image silently drops.
• Trigger: Any image fetched whose byte length is not divisible by 3.

Recommendation: Add two small cases:

it('should produce correct one-char padding (==)', async () => {
  // 'f' -> "Zg=="
  global.fetch = jest.fn().mockResolvedValue({
    ok: true,
    arrayBuffer: async () => new Uint8Array([0x66]).buffer,
    headers: { get: () => 'image/png' }
  }) as unknown as typeof fetch;
  const result = await new FetchUtil({ baseUrl }).fetchImage('/img');
  expect(result).toBe('data:image/png;base64,Zg==');
});

it('should produce correct two-char padding (=)', async () => {
  // 'fo' -> "Zm8="
  global.fetch = jest.fn().mockResolvedValue({
    ok: true,
    arrayBuffer: async () => new Uint8Array([0x66, 0x6f]).buffer,
    headers: { get: () => 'image/png' }
  }) as unknown as typeof fetch;
  const result = await new FetchUtil({ baseUrl }).fetchImage('/img');
  expect(result).toBe('data:image/png;base64,Zm8=');
});

Fix this →

---

Issue 2: Full content-type header (with params) embedded verbatim in data URL

ID: fetchutil-contenttype-dataurl-b8c2
File: packages/core/src/utils/FetchUtil.ts:96
Severity: LOW
Category: correctness

Context:

• Pattern: response.headers.get('content-type') is used as-is: data:${contentType};base64,.... Servers (or CDNs) occasionally return image/svg+xml; charset=utf-8 or image/png; quality=high.
• Risk: The resulting data URL becomes data:image/svg+xml; charset=utf-8;base64,.... Parsers that do strict tokenisation on ; may mis-identify the media type or fail to recognise ;base64.
• Impact: SVG or other image types that servers annotate with parameters may silently fail to render.
• Trigger: Any image endpoint that returns a content-type header containing a semicolon-delimited parameter.

Recommendation: Strip parameters before building the data URL:

// line 96
const rawContentType = response.headers.get('content-type') ?? 'image/png';
const contentType = rawContentType.split(';')[0]!.trim() || 'image/png';

Fix this →

[ignaciosantise]

@claude review

[claude]

Claude finished @ignaciosantise's task in 1m 26s —— View job

---

PR Review

• Gather context
• Read changed files
• Check existing issues from prior review
• Analyze and post findings

---

🔄 Incremental Review: Both issues flagged in the previous review have been addressed in subsequent commits.

Resolved since last review:

• fetchutil-test-padding-coverage-a3f1 — Padding tests added at FetchUtil.test.ts:145–171 covering both == (1-byte remainder) and = (2-byte remainder) cases.
• fetchutil-contenttype-dataurl-b8c2 — Content-type parameters are now stripped at FetchUtil.ts:99–100 (rawContentType.split(';')[0]?.trim() || 'image/png').

✅ No new issues found in latest commits.