feat: forward vendor function codes

[tma]

Summary

Fixes #13. mbproxy used to reject any function code outside the eight standard ones with Illegal Function. That blocked Huawei SUN2000 installer login and optimizer file transfer, both of which use 0x41. wlcrs/huawei_solar needs that for setup.

Weafdinstel confirmed the same failure after updates or configuration changes: setup has to go through another proxy first, then mbproxy can be used again.

Unknown function codes are now forwarded as opaque PDUs.

Behavior

• The inbound PDU is preserved and sent upstream unchanged.
• Vendor requests are not cached, coalesced, or retried.
• Genuine upstream exceptions keep their exception code.
• Transport, framing, and malformed exception responses still map to 0x0B.
• A missing or mismatched vendor PDU still returns Illegal Function locally and never reaches upstream.

Read-only mode still applies only to 0x05, 0x06, 0x0F, and 0x10. 0x41 is forwarded even when MODBUS_READONLY=true or deny, because we cannot invent a valid vendor response, and faking success would break login. If you use read-only as a safety interlock, vendor codes can still change device state.

Cached 0x03/0x04 values are left alone. If a vendor operation later changes register-mapped state, those values stay until TTL expiry. Huawei uses 0x41 as a separate channel, so I did not flush the cache.

Testing

• go fmt ./...
• go vet ./...
• go test -count=1 -race ./... in golang:1.24

Coverage includes Huawei 0x41 parse/forward, missing PDU rejection, no cache invalidation, forward under readonly=true and deny, no retry on transport failure, preserved vendor exceptions, and malformed vendor responses mapping to 0x0B.