Outputs.share() fails on Windows: shape/dim wires are sized as int32 but always read as int64

While working on a code block that shares a plain numeric array with `outputs.share()`, I found that the call fails immediately on Windows, before any block logic runs.

### What happens

`Outputs.share()` sizes the `_shape` and `_dim` wires from arrays built without an explicit dtype:

https://github.com/JdeRobot/VisualCircuit/blob/master/backend/staticfiles/synthesis/lib/outputs.py#L47-L48

```python
shape = np.array(data.shape)
dim = np.array([len(shape)])
```

`np.array([...])` uses the platform's default integer, which is **int32 on Windows** and int64 on Linux/macOS. Both buffers are then read back — here and in `inputs.py` — as `np.int64`:

```python
self.outputs[name]["dim"] = create_ndbuffer((1,), np.int64, dim_wire.buf)
```

So on Windows the wire gets 4 bytes and numpy is asked for an 8-byte view of it.

### Reproduction

```python
import multiprocessing, numpy as np
from lib.outputs import Outputs

print("numpy default int on this platform:", np.array([1]).dtype)

o = Outputs({"Out": {"wire": "demo_a", "lock": multiprocessing.Lock()}})
o.share("Out", np.arange(100, dtype=np.float64))
```

Output (Windows 11, Python 3.11, numpy 1.26.4), with a print added inside `_create_wire` to show the requested sizes:

```
numpy default int on this platform: int32
allocated demo_a_shape 4 bytes
allocated demo_a_dim 4 bytes
allocated demo_a_type 24 bytes
allocated demo_a 800 bytes
Traceback (most recent call last):
File "repro_a.py", line 16, in
o.share("Out", np.arange(100, dtype=np.float64))
File "lib\outputs.py", line 72, in share
self.outputs[name]["dim"] = create_ndbuffer((1,), np.int64, dim_wire.buf)
File "lib\utils.py", line 5, in create_ndbuffer
return np.ndarray(shape, dtype=dtype, buffer=buffer)
TypeError: buffer is too small for requested array
```

This is not data-dependent — every `share()` call fails the same way, so no circuit using a generic `share()` output can run on Windows at all. It goes unnoticed on the maintainers' side because on Linux the default int is already int64 and the sizes happen to line up.

### Why the other paths are fine

`_share_npy_matrix()` (used by `share_image` and `share_array`) already pins the dtype explicitly:

```python
dim = np.array([len(matrix.shape)], dtype=np.int64)
```

and `share_image()` passes `np.array(shape, dtype=np.int64)`. So it is only the generic `share()` that is inconsistent with the rest of the file.

### Suggested fix

Make `share()` match `_share_npy_matrix()`:

```python
shape = np.array(data.shape, dtype=np.int64)
dim = np.array([len(shape)], dtype=np.int64)
```

I have this verified locally and am happy to send a PR with it. There is a second, independent sizing bug in the same function that this fix exposes — I'll file that separately so the two can be reviewed on their own.

Start in backend/staticfiles/synthesis/lib/outputs.py at the shape and dim arrays in Outputs.share(), then compare them with _share_npy_matrix(). Check the corresponding reads in inputs.py and run the Windows reproduction with the provided numpy array. Done means generic share() no longer fails because the wire sizes and reads agree across platforms.

Written by the indexing model from the issue text.