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

Nobody has claimed this yet.

## 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.

Start with get_device_info() and the /cgi/json-req request flow, then reproduce the Device/DeviceInfo container failure and successful leaf reads on the F@ST 5364. Define completion as successful device-info retrieval from supported leaf paths while preserving independent action-level results when a request-level error is returned.

Written by the indexing model from the issue text.