[Java] ForyJson: no InputStream-based deserialization path

### Feature Request

`ForyJson` has no `InputStream`-based deserialization path. The public API (1.6.1) offers only:

```java
public T fromJson(String, Class);
public T fromJson(String, TypeRef);
public T fromJson(byte[], Class);
public T fromJson(byte[], TypeRef);
```

The write side already has one — `writeJsonTo(Object, OutputStream)` — so the asymmetry is only on read. The binary path has `ForyInputStream`; JSON has no equivalent.

### Is your feature request related to a problem? Please describe

We're integrating `fory-json` into the Quarkus extension for `quarkus-fory` (quarkiverse/quarkus-fory#193), implementing a JAX-RS `MessageBodyReader`. The reader is handed an `InputStream`, so the only option is:

```java
byte[] bytes = entityStream.readAllBytes();
return foryJson.fromJson(bytes, TypeRef.of(genericType));
```

Every request allocates a byte[] the size of the whole body, which is a poor fit for large payloads. Any integration that receives an `InputStream` — servlet/JAX-RS bodies, files, socket streams — hits the same thing.

### Describe the solution you'd like

Incremental parsing from an `InputStream`, so a document can be decoded without being fully resident.

We recognize this isn't a small addition: `JsonReader` is index-addressed (`charAt(int)`, `position()`, `scanStringEnd(int)`), which assumes random access over a resident buffer. Making it incremental means either a pull parser or a chunked buffer with bounded backtracking, and there's presumably a deliberate performance reason for the current design. So this is a request for your judgement on whether it fits Fory's goals, not a specific implementation proposal.

To be explicit about what would *not* help: a `fromJson(InputStream, ...)` convenience overload that calls `readAllBytes()` internally has the same memory profile as what callers write today.

### Describe alternatives you've considered

- `readAllBytes()` — what we do now; bounded by the framework's max-body-size setting
- Decoding to `String` first — strictly worse
- Chunked/streaming at the application protocol layer — pushes the problem to users

### Additional context

fory-json 1.6.1, Java. Happy to help test or contribute if you decide on a direction.

Start by tracing the public ForyJson fromJson overloads and the index-addressed JsonReader, then compare them with writeJsonTo(Object, OutputStream) and the binary ForyInputStream path. Determine whether an incremental InputStream design fits Fory's goals without calling readAllBytes(); done means an agreed, bounded-memory deserialization direction rather than a convenience overload with the same allocation profile.

Written by the indexing model from the issue text.