[Bug] HStore accepts writes with the default serializer=text and then fails every read with BufferUnderflowException; the backend should require serializer=binary

Start at CoreOptions.SERIALIZER and trace the HStoreProvider or store open path to determine where backend configuration is validated. Reproduce the mismatch with the shown POST and GET/list requests, then verify that an HStore graph cannot proceed with serializer=text and that the resulting message identifies the required binary serializer. Check the graph-config documentation for the corresponding note.

Bug Type (问题类型)

logic (逻辑设计问题): missing configuration validation

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

master 83ef9f3f, PD + 3 Stores + Server; also reproduced on a single-node PD + Store + Server deployment. Graph config file with backend=hstore, store, pd.peers and no serializer line.

Expected & Actual behavior (期望与实际表现)

Expected: a graph on HStore either refuses to open with a serializer it cannot read, or picks the only one it supports.

Actual: CoreOptions.SERIALIZER defaults to text. The shipped hugegraph.properties sets serializer=binary explicitly; a hand-written graph file usually does not. With text the write path serialises rows through TextSerializer and HStore stores them, but HstoreTable.newEntryIterator always parses returned keys as binary (new BinaryBackendEntry(type, col.name)): a text key such as marko starts with 0x6d, so readId() takes the number branch and readNumber() runs off the end of the buffer.

POST /graph/vertices {"label":"person","id":"marko",...}   -> 201, the vertex is echoed back
GET  /graph/vertices/"marko"                               -> 404 Vertex 'marko' does not exist
GET  /graph/vertices?limit=10                               -> 500 java.nio.BufferUnderflowException
g.V().count()                                               -> 3 (rows are counted, not parsed)
g.V().limit(3).valueMap(true)                               -> BufferUnderflowException
server log: Failed to parse entry: 0x533e6578706972: [S>expired_time=0]

Stack (identical on both deployments): BytesBuffer.readShort:327 ← readUInt16:457 ← readNumber:983 ← readId:761 ← parseId:855 ← BinaryBackendEntry.<init>:44 ← HstoreTable.lambda$newEntryIterator$1:121 ← BinaryEntryIterator.fetch:86 ← … ← VertexAPI.list.

Why it costs people time

The failure is far from the cause: writes succeed, the schema API works, the error is a low-level buffer exception in the read path, and nothing in the log mentions the serializer. On the second deployment this was chased through jar checksums, Java versions and data wipes for an hour before the config line was found. The HStore backend has exactly one serializer it can read, so the option is not a choice there.

Proposal (small, I can send the PR)

1. HstoreProvider (or the store open path) checks the graph's serializer and fails fast with a clear message when it is not binary: HStore backend requires serializer=binary, but got 'text' (graph 'smoketext'). The same guard makes sense for any backend whose tables are binary-only.
2. Alternatively, default the option per backend: hstore and rocksdb imply binary when the line is absent, with an INFO line saying so.
3. A note in the graph-config documentation: serializer is not optional for hstore.

Related: #3090 (property codec between server and store) is a different topic; this one is purely a missing configuration guard.