Outputs.share() under-allocates the data wire whenever check_type() promotes the dtype

`Outputs.share()` decides how much shared memory the data wire needs *before* it decides what dtype it is going to store there, and the two do not agree.

### What happens

`check_type()` deliberately widens the dtype — int32/float32 are promoted to 64-bit, and any Unicode/bytes dtype is promoted to at least 64 characters:

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

But the wire is allocated from the **original**, un-promoted `nbytes`:

```python
data_size = data.nbytes if data.nbytes > 256 else 256
data_wire = self._create_wire(self.outputs[name]["wire"], data_size)
...
self.outputs[name]["data"] = create_ndbuffer(shape, type[0], data_wire.buf) # promoted dtype
```

So whenever promotion actually changes the itemsize and the promoted size exceeds both `data.nbytes` and the 256-byte floor, the view is larger than the buffer and numpy refuses it.

### Reproduction

```python
o = Outputs({"Out": {"wire": "demo_b", "lock": multiprocessing.Lock()}})
o.share("Out", ["cat", "dog", "bird"])
```

I'm on Windows, where #483 fires first, so to isolate *this* bug I patched only the shape/dim dtype line out and ran a few payloads through the shipped code:

```
payload dtype -> promoted allocated needed result
list of strings

Start in backend/staticfiles/synthesis/lib/outputs.py, reading check_type() and Outputs.share() together. Reproduce the string, float32, int32, and scalar payloads described in the issue, then verify that promoted dtypes receive enough shared memory and scalar shape wires have positive sizes. Done means these cases no longer raise buffer-size or zero-size errors.

Written by the indexing model from the issue text.