fix(SearchBar): remove stray key field spread into Icon props

[tpaulshippy]

Summary

All three SearchBar variants (SearchBar-ios, SearchBar-android, SearchBar-default) render the clear ("X") button via:

renderNode(Icon, clearIcon, {
  ...defaultClearIcon(theme),
  key: 'cancel',
  onPress: handleClear,
})

renderNode spreads this object directly into JSX (<Icon {...defaultProps} {...content} />), and since the object includes a literal key: 'cancel' field, this triggers React's dev-mode warning on every render where the clear icon is shown (i.e. whenever the search input is non-empty):

Warning: A props object containing a "key" prop is being spread into JSX:
  let props = {key: someKey, type: ..., name: ..., size: ..., color: ..., onPress: ...};
  <Themed.Icon {...props} />
React keys must be passed directly to JSX without using spread:
  let props = {type: ..., name: ..., size: ..., color: ..., onPress: ...};
  <Themed.Icon key={someKey} {...props} />

Why this is safe to remove

The key field serves no purpose here — Icon isn't part of a list being reconciled, and React's JSX runtime strips key out of spread props before the component ever receives it, in both dev and production builds. See jsxProd in react/cjs/react-jsx-runtime.production.js:

function jsxProd(type, config, maybeKey) {
  ...
  if ("key" in config) {
    maybeKey = {};
    for (var propName in config)
      "key" !== propName && (maybeKey[propName] = config[propName]); // key is always stripped
  } else maybeKey = config;
  ...
}

So removing this field has no behavioral or visual effect on SearchBar or Icon in any build — it only silences the dev-mode warning.

Real-world impact

In a consuming app using Expo Go/dev-client, this warning surfaces as an in-app error banner pinned to the bottom of the screen. That banner can intermittently overlap other bottom-pinned UI (e.g. a fixed nav footer button) and cause automated E2E tests that assert strict tap visibility/hittability (e.g. Detox on iOS) to fail flakily whenever a user has typed something into a SearchBar earlier in the flow.

Closes #4035

Test plan

• Existing SearchBar-ios/SearchBar-android/SearchBar-default snapshot tests pass unchanged (no snapshot updates needed — key isn't part of the serialized output).
• Manually verified in a consuming app (Expo Go, iOS simulator) that typing into a SearchBar no longer triggers the "props object containing a key prop" warning/banner.