fix(outputs): size shared-memory wires from promoted dtype

[harsh839]

Fixes #483 and #484.

Outputs.share() decided how much shared memory the shape/dim/data wires
need before deciding what dtype it would store there, and the two did
not agree:

• In Outputs.share() fails on Windows: shape/dim wires are sized as int32 but always read as int64 #483 (Windows): shape and dim are built from
  platform-default integers (np.array(data.shape) → int32 on
  Windows), but the buffers are always read back as np.int64 in
  outputs.py and inputs.py. The wire gets 4 bytes and numpy is asked
  for an 8-byte view, so every share() call fails with
  TypeError: buffer is too small for requested array.
• In Outputs.share() under-allocates the data wire whenever check_type() promotes the dtype #484 (.py lines 46-48): the data wire is allocated from the
  un-promoted data.nbytes, but the buffer is then viewed with the
  check_type()-promoted dtype (int32→int64, float32→float64,
  U/S→U64). Whenever promotion increases the itemsize past both the
  input nbytes and the 256-byte floor, the view is larger than the
  buffer (e.g. a float32 array straight out of a model, or a list of
  class labels), and numpy refuses it.
• Scalar payloads (share("Out", 5), share("Out", "hello")) produced a
  0-sized shape wire, which SharedMemory rejects, and then a 0-d
  write through [:], which numpy rejects.

Changes

• Build shape/dim explicitly as np.int64, fixing the Windows
  int32/int64 mismatch (Outputs.share() fails on Windows: shape/dim wires are sized as int32 but always read as int64 #483).
• Size the data wire from the promoted dtype
  (data.size * np.dtype(final_type).itemsize) with the existing
  256-byte floor, so the later create_ndbuffer(...) view always fits
  (Outputs.share() under-allocates the data wire whenever check_type() promotes the dtype #484).
• Floor the shape wire at one int64 so 0-d (scalar) payloads are
  creatable, and marshal via ... indexing so 0-d and N-d payloads both
  write correctly.

Verification

Tested with a real two-process round-trip (writer block process →
reader block process, the architecture the runtime uses) covering
float32, float16, int32, uint8, float64, 2-D arrays, lists of
strings (<U64 promotion), and both scalar int/string payloads. All
share/read round-trips now pass on Linux; the shape/dim fixes are the
exact dtypes the reader already expects, which is what makes Windows
work. Previously #484 fails deterministically on Linux for any payload
larger than 256 bytes whose dtype gets promoted.

Note: this branch intentionally leaves formatting untouched so the PR
stays a focused logic fix; the formatting-only PR (#444) on top of
master may need a one-line rebase once this merges.

[harsh839]

@jmplaza could you take a look when you get a chance? This sizes the shared-memory output wires using the promoted dtype so promoted types (e.g. float32->float64) don't overflow their buffers.