docs(sql): TRUNCATE TYPE / TRUNCATE BUCKET document their transactional behaviour

[lvca]

Companion to ArcadeData/arcadedb#6225 (fixes ArcadeData/arcadedb#6220).

Both TRUNCATE reference pages described what the command deletes and said nothing about what a ROLLBACK after it does. Until v26.9.1 the answer was "almost nothing": the statement committed the caller's transaction from the inside - dropping the type's indexes, then committing once per arcadedb.truncateBatchSize records - so a rollback recovered at most the records of the last uncommitted batch, and none at all when the type had any index.

The behaviour now depends on whether a transaction is active when the command runs, and that is also how a user chooses between the two paths:

• inside a transaction, the truncate is part of it and a ROLLBACK puts every record back (transactional: true);
• with none active, the command owns a transaction of its own and takes the faster drop-indexes / batch-delete / rebuild path, which commits as it goes and cannot be undone (transactional: false).

Over HTTP the request's auto-commit transaction decides, so "autoCommit": false selects the faster path.

Each page gains a Transactions section saying this, names the transactional field the result set now reports, and carries a NOTE about the pre-26.9.1 behaviour for anyone reading against an older server.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request