Native: single-record UPDATE through command() is about 26 percent slower on post3 than on 26.11.1 in the l1tpc paper cells #400

In the paper cells of the documents lane (l1tpc, the OLTP workload, native wheel, embedded arm, relaxed durability), the single-record UPDATE is slower on 26.11.1.post3 than on 26.11.1, at both table sizes, and insert and delete are not. The operation is db.begin(), then db.command("sql", "UPDATE Crud SET qty = 2 WHERE ckey=:c", {...}), then db.commit(); insert and delete have the same shape. These are the p50 times per operation of three repetitions each, measured on the same host with the same harness settings (the 26.11.1 rows are the first three passes, the post3 rows are the rerun of 2026-11-14):

The update repetitions of each arm agree closely with each other (0.084, 0.083, 0.085 against 0.106, 0.105, 0.106 at the small size), so the difference is not noise between repetitions. It is about 26% or 22 microseconds per update. The post3 timed A/B (#315) did not see it: its one-row update figure runs set and save() inside explicit transactions with auto-transaction off, which is another path, and it has no command("sql", "UPDATE ...") figure.

What I do not know is which release introduced it. Between 26.11.1 and 26.11.1.post3 the native wheel changed in post1 (a create or update reads its row in the crossing of the statement, #329), in post2, and in post3 (#384, #385), so the cause can be any of them. I will bisect with a timed A/B of this exact shape (begin, UPDATE through command, commit, with insert and delete as controls) on the published wheels 26.11.1, 26.11.1.post1, 26.11.1.post2 and 26.11.1.post3, and post the table here. The paper row of this cell is the post3 row for now, as decided, and it is replaced if a later wheel fixes this.

Related: #315, #329.