fix(apple): make cancelling a targeted send actually cancel

Creating a targeted transfer contacts the peer and only returns once the
offer is answered or its timeouts expire — connection_timeout plus
offer_wait_timeout, so minutes against a device that never answers. The
composer disabled every control for that whole window, including Close,
leaving no way out. Worse, the core records the row before it reaches out
and leaves it in `failed` when the peer never replies, so giving up still
produced a failure notification and a history entry for a send the user
had already called off.

Cancelling now reaches the core while that create is still running. The
`created` lifecycle event carries the transfer id and is emitted before
the peer is contacted, so the id is known in time; the cancel goes out
through the interrupt lane, which exists precisely to reach a core busy
inside another call. The transfer is then deleted, and its id is filtered
out of the published list so a refresh racing the delete cannot leak it
into history or into a notification. If the id has not arrived yet, the
result carries it and the same cleanup runs on return. Picked sources are
released only once the call lands, because the import owns them until
then, and a generation counter keeps a late result from disturbing a
newer send.

Close and Cancel were also the same action under two labels. There is now
one control: the sheet's cancellation item, reading Cancel while a send is
waiting and Close otherwise, never disabled.

Two further fixes from device testing:

- Receive and Resume were gated on transfer state alone, so an approved
  outgoing transfer offered the sender a Receive button — an invitation to
  download the files it was uploading. Both pull into a local folder and
  are now receiver-only.
- Renamed the deprecated `laptopcomputerAndIphone` symbol to
  `macbookAndIphone`; the deployment targets are well past where it was
  introduced, so no availability guard is needed.

Adds a typed `targetedTransferId` accessor on CoreEventModel. This is a
narrow, deliberate exception to the wake-up-only event rule in
DESIGN-DEVICE-HISTORY.md §13: it takes the subject id and never state,
and it exists because no query can answer while the create holds the
serial lane — which is exactly when the user wants to cancel.

Known gap: direction is inferred by comparing endpoint ids, because the
binding does not expose the row's role. After an identity reset, rows
predating it match neither endpoint, so past sends read as incoming from
the device's own retired identity. Fixing that needs `role` on the core's
TargetedTransfer.

localization/strings.json

@@ -5485,6 +5485,21 @@
         "ru": "Transfer offer sent"
       }
     },
+    "saved_devices_send_waiting": {
+      "context": "Progress label while a targeted transfer offer is waiting for the receiving device to answer.",
+      "targets": ["apple"],
+      "translations": {
+        "en": "Waiting for the device to answer…",
+        "fr": "Waiting for the device to answer…",
+        "es": "Waiting for the device to answer…",
+        "it": "Waiting for the device to answer…",
+        "de": "Waiting for the device to answer…",
+        "pt": "Waiting for the device to answer…",
+        "pl": "Waiting for the device to answer…",
+        "nl": "Waiting for the device to answer…",
+        "ru": "Waiting for the device to answer…"
+      }
+    },
     "saved_devices_forgotten": {
       "context": "Snackbar after forgetting a saved device.",
       "translations": {