docs: add the DECIMAL property data type

[SebastianGruza]

Purpose of the PR

Docs for the DECIMAL property data type: apache/hugegraph#3209 (server) and apache/hugegraph-toolchain#771 (client, loader, hubble, spark). Paired docs change requested in the review of #3209.

Main Changes

• restful-api/propertykey.md (en, cn): decimal in the data_type list, with its bounds (at most 128 significant digits, scale within ±128) and the wire form (a plain JSON number with every digit, so a client must not parse it as a double).
• clients/hugegraph-client.md (en, cn): asDecimal() | BigDecimal in the data type table.

Verifying these changes

Markdown only; the wording matches the constants and behaviour in the two PRs (DataType.DECIMAL_MAX_PRECISION/SCALE, PropertiesDeserializer, BigDecimalSerializer).

🤖 Generated with Claude Code

[imbajin]

Blocking: yes. Summary: The new REST contract says DECIMAL responses are JSON numbers, but the paired server head serializes BigDecimal responses as strings, so clients following this text may decode them incorrectly. Evidence: apache/hugegraph at 0bb7724a406d9ee49ab5bfee719aa440ee6ab002 registers a BigDecimal string serializer in JsonUtil; JsonUtilTest confirms quoted output.

[imbajin]

⚠️ Important. This says DECIMAL requests and responses both use JSON numbers, but paired server PR #3209 at head 0bb7724a406d9ee49ab5bfee719aa440ee6ab002 serializes REST BigDecimal responses as JSON strings. Please distinguish accepted exact JSON number/string inputs from string responses, and update the parallel Chinese paragraph too. Evidence: server JsonUtil registers BigDecimalSerializer, whose serialize() calls writeString(); JsonUtilTest.testSerializeBigDecimal() asserts quoted output.

[SebastianGruza]

Right. Now: in a request a JSON number or a string, both read exactly; in a response a string (example "amount": "12345678901234567890.123456789012345678"), which a client parses with new BigDecimal(String), never as a double. The Chinese paragraph says the same.

[SebastianGruza]

Updated in 4e4d3f1: DECIMAL is accepted as a JSON number or a string and returned as a string, in both languages; matches apache/hugegraph#3209 at d7eb80c8.

[bitflicker64]

Blocking: yes. Summary: The DECIMAL text now matches the paired server head: bounds of 128 digits and scale within plus or minus 128, exact JSON number or string input, string output. Two gaps remain: these pages document current master, which has no DECIMAL type or asDecimal() yet, and the new text does not say that a decimal key cannot be indexed, used as a primary key or sort key, or given an OLAP index write type. Evidence: apache/hugegraph#3209 at d7eb80c8 (DataType.DECIMAL_MAX_PRECISION/SCALE and checkDecimalBounds, PropertiesDeserializer.readValue, HugeGraphSONModule.BigDecimalSerializer registered into JsonUtil through registerCommonSerializers, VertexApiTest string assertions, the isDecimal() checks in VertexLabelBuilder, EdgeLabelBuilder, IndexLabelBuilder and PropertyKeyBuilder); apache/hugegraph-toolchain#771 at 991a97f7 adds PropertyKey.Builder.asDecimal(); master DataType.java and client PropertyKey.java contain no DECIMAL or asDecimal; restful-api/_index.md says the section documents current master; no CI checks are reported on this head.

[bitflicker64]

Important: Merging this before apache/hugegraph#3209 and apache/hugegraph-toolchain#771 documents a type that master does not have. restful-api/_index.md says this section documents current master, and this client guide follows master too. Today DataType.java on hugegraph master has no DECIMAL, and PropertyKey.Builder on toolchain master has no asDecimal(). A reader who sends "data_type": "DECIMAL" or calls asDecimal() gets an error. Both code PRs are still open (server head d7eb80c8, toolchain head 991a97f7). Please hold this PR until both are merged, or mark the type with the release it ships in. This applies to the matching lines in content/cn too.

[bitflicker64]

Minor: The new decimal text does not list the limits that #3209 enforces. At d7eb80c8 the server rejects a decimal key as an index field of any type (IndexLabelBuilder), as a vertex primary key (VertexLabelBuilder), as an edge sort key (EdgeLabelBuilder), and with write type OLAP_SECONDARY or OLAP_RANGE (PropertyKeyBuilder, only OLAP_COMMON is allowed). The errors are clear, but a user designing a schema from this page finds out only at creation time. Could you add one sentence here and in the Chinese page, for example: a decimal key cannot be indexed, used as a primary key or sort key, or set to an OLAP index write type? The writeType table in hugegraph-client.md could carry the same note.