Ambiguity in the `UniqueConstraint` of `Signal`

**Note:** This issue is a follow-up to the previous schema discussion about `Signal` field semantics in #5.

Currently, the `Signal` table uses this identity constraint:

```python
UniqueConstraint("machine", "experiment_id", "diagnostic", name="uq_signal_identity")
```

but `"diagnostic"` is nullable:

```python
diagnostic: Mapped[Optional[str]] = mapped_column(String(255))
```

This raises two design questions:

1. One diagnostic family may correspond to multiple channels/signals in the same experiment (for example, multiple accelerometers or thermocouples under the same instrumentation family). If, for a given `(machine, experiment_id)` tuple, identity is based only on `diagnostic`, multichannel systems force either artificial channel naming inside the `diagnostic` field or loss of channel-level uniqueness. That can make data usage inconsistent and queries less reliable.

2. Because `diagnostic` is nullable, the unique constraint does not fully protect identity when `diagnostic` is missing (`NULL`), since (if I'm not wrong) in SQLite and MySQL, `UNIQUE` constraints allow multiple rows where `diagnostic` is `NULL`. This weakens the assumption that the current key always guarantees one row per identity tuple.

It goes a bit beyond the scope of the current issue, but this also raises another question about the intended role of the `Signal` table:

1. Should one row in the `Signal` table represent one physical signal/channel across all experiments (i.e., a global identity)? It would be a database of all recorded channels (diagnostics and machine/plant instrumentation), each with a unique entry, if you will. This is not the case with the current schema, and in this case, the `experiment_id` field should belong somewhere else.

2. Should `Signal` represent an "experiment-specific" signal instance, as is the case now? That means we can have the same "physical" signal (e.g. a given sensor) appear multiple times in this table provided it has two different values of `experiment_id`.

This choice impacts the correct unique key and table design. In the previous issue (#5), I proposed introducing other fields, in particular a signal-specific identifier such as `tag` to uniquely identify each signal, which could be part of the `UniqueConstraint` depending on the choice between points 1 and 2 above.