Unhashable type for Systec interface errors

### Describe the bug
When running DroneCAN on top of the systec interface, error messages that appear raise `TypeError: unhashable type` exceptions. This swallows the actual error messages and prevents troubleshooting.

The cause of error messages is likely a config/hardware issue, so it is probably irrelevant. What matters is that the **CAN error messages disappear and are not relayed to the user.**

### To Reproduce
Below is a script to monitor messages coming through DroneCAN. Error messages do not always happen, but they tend to be triggered by sending commands through DroneCAN.

The actual mechanism triggering error messages is more likely a config/hardware issue than anything.

### Expected behavior

The error message raised during operation should be exposed to the user.

### Additional context

OS and version: Windows 11
Python version: 3.10
python-can version:
python-can interface/s (if applicable): systec

Traceback and logs

Traceback:
```
Traceback (most recent call last):
File "c:\Users\thoma\OneDrive\Documents\Tyto\Python scripts\test.py", line 51, in
dc_node.spin(timeout=0.001)
File "C:\Python310\lib\site-packages\dronecan\node.py", line 439, in spin
execute_once()
File "C:\Python310\lib\site-packages\dronecan\node.py", line 431, in execute_once
frame = self._can_driver.receive(read_timeout)
File "C:\Python310\lib\site-packages\dronecan\driver\python_can.py", line 137, in receive
self._check_write_feedback()
File "C:\Python310\lib\site-packages\dronecan\driver\python_can.py", line 124, in _check_write_feedback
raise item
File "C:\Python310\lib\site-packages\dronecan\driver\python_can.py", line 101, in _writer_thread_loop
self._bus.send(msg)
File "C:\Python310\lib\site-packages\can\interfaces\systec\ucanbus.py", line 212, in send
self._ucan.write_can_msg(self.channel, [message])
File "C:\Python310\lib\site-packages\can\interfaces\systec\ucan.py", line 488, in write_can_msg
UcanWriteCanMsgEx(self._handle, channel, c_can_msg, c_count)
File "C:\Python310\lib\site-packages\can\interfaces\systec\ucan.py", line 109, in check_result
raise UcanError(result, func, arguments)
File "C:\Python310\lib\site-packages\can\interfaces\systec\exceptions.py", line 16, in __init__
message = self._error_message_mapping.get(result, "unknown")
TypeError: unhashable type
```

Script to recreate the bug:
```py
import can
import dronecan
from dronecan.driver import python_can as pycan_driver
from dronecan.app.node_monitor import NodeMonitor
import time

can_bus = pycan_driver.PythonCAN(channel=0, interface="systec", bustype="systec", bitrate=1000000)

node_id = 45

dc_node = dronecan.node.Node(can_bus, node_id=node_id, bitrate=1000000)

print("=== Local Node ===")
print(f" node_id : {dc_node.node_id}")
print(f" mode : {dc_node.mode}")
print(f" health : {dc_node.health}")
print()

# Print every NodeStatus as it is received:

def on_node_status(event):

print(
f"[NodeStatus] from node {event.transfer.source_node_id}: "
f"uptime={event.message.uptime_sec}s "
f"health={event.message.health} "
f"mode={event.message.mode}"
)

dc_node.add_handler(dronecan.uavcan.protocol.NodeStatus, on_node_status)

LISTEN_SECONDS = 10

monitor = NodeMonitor(dc_node)

print(f"Listening for {LISTEN_SECONDS} seconds...\n")
deadline = time.monotonic() + LISTEN_SECONDS
while time.monotonic() < deadline:
try:
dc_node.spin(timeout=0.001)
msg = dronecan.uavcan.equipment.esc.RPMCommand()
msg.cmd = int(0)
dc_node.broadcast(msg)
except dronecan.transport.TransferError as ex:
print(f" (transfer error, continuing: {ex})")

dc_node.close()
```

With Claude, I tracked down the error to `interfaces/systec/exceptions.py`. A `ctypes.c_ubyte` error code is passed to the Python interface, and the systec backend fails to interpret it. By changing Line 16 in `exceptions.py`, I can see the underlying exception and original error message:

```py
message = self._error_message_mapping.get(result, "unknown")
```
should become
```py
message = self._error_message_mapping.get(result.value, "unknown")
```

This seems to have solved the issue, and now I can troubleshoot my hardware problems better. I cannot make a PR for this at the moment, but I might later.

Start with UcanError.__init__ in can/interfaces/systec/exceptions.py and trace the result passed by check_result in can/interfaces/systec/ucan.py. The report identifies a ctypes.c_ubyte error code and a specific failing lookup. Verify that constructing the exception exposes the original CAN error rather than raising TypeError; the supplied DroneCAN script provides an integration check when Systec hardware is available.

Escrito por el modelo de indexación a partir del texto del issue.