fix(settings): Skip pairing channel close once the socket is gone

[dschom]

Because

• A socket error disconnects the pairing channel without firing close, so the
  authority's teardown calls into a dead channel and fxa-pairing-channel's own
  close() throws.
• The throw is already caught, so no user flow breaks — but it has reported 43
  TypeErrors to Sentry on stage since 27 Aug, crowding out real pairing failures.
• The supplicant's cancel path reaches the same line and has reported 1646
  TypeErrors in prod since 30 Apr (FXA-CONTENT-1K0J).

This pull request

• Skips the underlying close() in PairingChannelClient when
  fxa-pairing-channel has already dropped the socket.
• Adds a regression test covering close after a socket error.

Issue that this pull request solves

Closes: FXA-14443
Closes: FXA-14445

Checklist

Put an x in the boxes that apply

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).
• I have manually reviewed all AI generated code.

How to review (Optional)

• Key files/areas to focus on:
• Suggested review order:
• Risky or complex parts:

Screenshots (Optional)

Please attach the screenshots of the changes made in case of change in user interface.

Other information (Optional)

• The guard tests _connection === null rather than falsy on purpose. Only
  null means the package tore the socket down; if a future version renames or
  removes the property it reads as undefined and falls through to the existing
  try/catch-guarded close(), rather than silently leaving channels open.
• pairing-channel.ts and pairing-authority-integration.ts carry leftover
  console.info / console.warn debug logging from 3155801. Left untouched
  here — worth a separate cleanup.