Native point operations: cut the repeated Python work around the one crossing #229

On the native build a point operation is one call into the library plus one call to free the reply, so the engine's share of it is small and the Python around it is most of the time. A discovery pass on the native wheel (untimed profile, each path run 1500 times; the shares are directions, not a speed claim) gives:

The crossings are already minimal (one entry and the reply free). What remains is Python work that is repeated on every call and that the code shows is not needed:

• A parameter map that holds a record id ({"rid": RID}, which every edge end and every step sends) goes through the general encoder in codec.encode_params: _prep, a hook closure, a fresh JSONEncoder per call. A map of plain values takes the same detour. The text it produces is fixed by the values, so the cached encoder can write it.
• Database.lookup_by_key imports a module on every call, builds its JSON through the same general encoder, and builds a NativeResultSet (a cursor object with a deque) to hand out one row and close it.
• Edge.get_in, Edge.get_out and the steps (get_out_edges, get_in_edges, get_both_edges) build the same statement text again for every record, and a step makes a NativeResult for every row only to wrap it as a record. Each record then copies a property dict that nothing else references.

The change keeps every result, statement text and error message as it is. lookup_by_rid keeps the record id in its text (a timed A/B found the parameter path slower there, and tests/test_native_statement_texts.py pins it), so its cut is the smaller one of skipping the property copy.

Plan: a draft PR with the cuts and tests that spy on the codec, the cursor, the row object and the statement text objects (they fail on main and pass with the cut), and a pre-registered timed A/B against the main wheel before it leaves draft. Python only, no Java entry changes.