network_json_query returns stale fn_bytes_read when the query has no result

### Summary

In `atari/src/fn_network/network_json_query.s`, the `no_data` path
(DVSTAT reports 0 bytes) falls through to:

```asm
no_data:
jsr add_nul
; return the byte count
ldx _fn_bytes_read+1
lda _fn_bytes_read
rts
```

`_fn_bytes_read` is only assigned in the read path, so an empty query
result returns whatever byte count a *previous* operation left there.
The caller cannot distinguish "no value found" from "N bytes read"
(we observed a hard-to-debug bogus return of 59 with an empty output
buffer). The function should explicitly return 0 here.

While in the area: the file's own TODO -
`; TODO: how do we deal with very large json results?` - is a real
concern; the result is read in a single SIO frame sized by DVSTAT,
which for multi-KB values makes one very long, retry-prone transfer
(see firmware issue 1 for what a retry then does).

Open atari/src/fn_network/network_json_query.s and start at the no_data path after the DVSTAT zero-byte result. Ensure an empty query returns 0 rather than the previous _fn_bytes_read value, then verify that an empty output buffer no longer reports a stale count; the large-result TODO is a separate concern to keep scoped separately.

Written by the indexing model from the issue text.