TalkTalk Wi-Fi Hub (F@ST 5364) firmware SG4K100208: Device/DeviceInfo container blocked, leaf fallback works; Device/Hosts/Hosts works; DSL rates + throughput paths confirmed; request-level errors can mask per-action success

まだ誰も着手していません。

## Model information

| Key | Value |
|------------------|-------|
| Model name | F@ST 5364 (TalkTalk Wi-Fi Hub) |
| Hardware Version | F@ST 5364 |
| Software Version | External: SG4K100208 / Internal: 15.24.42_Prod |

## Describe the bug

On the TalkTalk-branded F@ST 5364, reading the `Device/DeviceInfo` container node fails with `XMO_UNKNOWN_PATH_ERR`, causing `get_device_info()` in python-sagemcom-api to raise an `UnknownPathException`.

However, individual leaf values under `Device/DeviceInfo/*` are readable and return valid data. This suggests the container is intentionally blocked while leaf access remains supported.

## To Reproduce

1. Authenticate successfully via `/cgi/json-req` using a `logIn` action.
2. Attempt to read the container node:
```
Device/DeviceInfo
```
3. Observe error:
```
XMO_UNKNOWN_PATH_ERR
```
4. Read individual leaf paths instead:
```
Device/DeviceInfo/ProductClass
Device/DeviceInfo/InternalFirmwareVersion
Device/DeviceInfo/ExternalFirmwareVersion
Device/DeviceInfo/UpTime
```
5. Observe valid values returned for all leaf paths.

## Expected behavior

`get_device_info()` should succeed on this model.

A possible approach is to fall back to querying known `Device/DeviceInfo` leaf values when the container node returns `XMO_UNKNOWN_PATH_ERR`, and construct a minimal device info object from those values.

## Screenshots

N/A – reproduced via API/XHR calls and browser console (`$.xmo.*`), not GUI interactions.

## Additional context

Other confirmed working paths on this model:

- Hosts:
```
Device/Hosts/Hosts
```
Returns a full list of host objects (MAC, IP, active state, interface type, etc.).

- DSL negotiated rates:
```
Device/DSL/Channels/Channel[@uid='1']/DownstreamCurrRate
Device/DSL/Channels/Channel[@uid='1']/UpstreamCurrRate
```

- Throughput counters without running a speed test:
- LAN:
```
Device/Ethernet/Interfaces/Interface[Alias="PHYx"]/Stats/*
```
- WAN:
```
Device/IP/Interfaces/Interface[Alias="IP_DATA"]/Stats/*
```

Notable quirks observed:

- Multi-action `/cgi/json-req` requests may return a request-level error even when individual actions succeed; action-level results should be evaluated independently.
- Some container nodes are blocked while their leaf children remain accessible (as seen with `Device/DeviceInfo`).
- SFP-related paths appear unsupported on this firmware and return errors.

All MAC addresses, IP addresses, auth tokens, nonces, and session identifiers have been redacted or replaced.

get_device_info() と /cgi/json-req リクエストフローから始め、F@ST 5364 で Device/DeviceInfo コンテナの失敗とリーフの読み取り成功を再現します。完了条件は、サポートされているリーフパスからデバイス情報を正常に取得し、リクエストレベルのエラーが返された場合でもアクションレベルの結果を独立して保持することとします。

索引モデルが issue の本文から書いたものです。