nodeApi: extract the shared slot-handle core (identity, accessors, patching)

Follow-up owned from review of #16790 (thread on `slotHandle.ts`, raised P3).

## Context

`createInputHandle` and `createOutputHandle` each re-implement the same mechanics: stable `id`, volatile `index`, `name`/`type`/`label` reads, `isConnected`, deleted-state guards, `modify()` patching and `snapshot()`.

## Decision

Ticket, low priority, and **deliberately scoped**. Extract the shared identity/accessor/patch/deleted-state core. Do **not** unify the link surfaces: an input has at most one link (`link()`, `source()`, `resolvedSource()`, argument-less `disconnect()`) while an output has many (`links()`, `targets()`, `connectTo()`, `disconnect(targetNodeId?)`, `moveLinksTo()`). That cardinality difference is real, it is visible in the published contract, and collapsing it into one generic shape would produce a worse API than the duplication it removes — a handle whose methods are half-meaningless depending on which side it came from.

So this is accepted in part and rejected in part, rather than taken whole.

## Done looks like

- One shared factory for the common members, parameterised by side
- Input- and output-specific link surfaces left as separate, explicit implementations
- `InputSlotHandle` and `OutputSlotHandle` unchanged as published types

Start in slotHandle.ts by comparing createInputHandle and createOutputHandle, identifying the shared identity, accessor, patching, and deleted-state behavior. Extract one parameterized factory while keeping each handle’s link methods separate. Done means the published InputSlotHandle and OutputSlotHandle types remain unchanged and only the common implementation is shared.

Written by the indexing model from the issue text.