## Code Analysis

### Rollback contract
`testing/go/smoke_test.go:43-53`
```go
{
    Query: "BEGIN",
},
{
    Query: "CREATE TABLE rolled_back AS SELECT 1 AS v",
},
{
    Query: "ROLLBACK",
},
{
    Query:    "SELECT to_regclass('rolled_back')",
    Expected: []sql.Row{{nil}},
},
```
The existing repository test establishes that a table created after `BEGIN` is absent after `ROLLBACK`. BF-FAIL-3 exercises the same contract with a conversion failure and an independent connection readback.

### Transaction-control path
`server/connection_transaction.go:99-102,212-219`
```go
case *sqlparser.Rollback:
	h.state.txState = idleTransactionState
	h.clearTransactionLocalVars()
	return false, nil

// runEngineTransactionControl executes an internal transaction-control statement without client responses.
func (h *ConnectionHandler) runEngineTransactionControl(statement string) error {
	queries, err := h.convertQuery(statement)
	if err != nil {
		return err
	}
	return h.doltgresHandler.ComQuery(context.Background(), h.mysqlConn, queries[0].String, queries[0].AST, func(*sql.Context, *Result) error { return nil })
}
```
The connection handler clears its protocol transaction state for `ROLLBACK` and routes engine transaction control through `ComQuery`. The observed durable table therefore concerns the engine transaction boundary, not only the client-visible state flag. The tested checkout also uses `github.com/dolthub/go-mysql-server v0.20.1-0.20260923233949-d8613573a711` in `go.mod:12`.

### Observed transaction and recovery

```text
$ docker exec 576e039362b1 bash -c "PGPASSWORD=password psql -X -h 127.0.0.1 -p 5432 -U postgres -d postgres --echo-all -v ON_ERROR_STOP=0 ..."
DROP TABLE IF EXISTS bf_fail3_valid;
DROP TABLE
DROP TABLE IF EXISTS bf_fail3_partial;
DROP TABLE
CREATE TABLE bf_fail3_valid (id INT PRIMARY KEY, amount INT);
CREATE TABLE
BEGIN;
BEGIN
CREATE TABLE bf_fail3_partial (id INT PRIMARY KEY);
CREATE TABLE
INSERT INTO bf_fail3_partial (id) VALUES ('deliberately-incompatible');
ERROR:  invalid input syntax for type int4: "deliberately-incompatible"
ROLLBACK;
ROLLBACK
INSERT INTO bf_fail3_valid (id, amount) VALUES (1, 42);
INSERT 0 1
COMMIT;
COMMIT
SELECT id, amount FROM bf_fail3_valid ORDER BY id;
 id | amount
----+--------
  1 |     42
(1 row)
```

### Independent schema readback

```sql
SELECT table_name FROM information_schema.tables WHERE table_name IN ('bf_fail3_partial','bf_fail3_valid') ORDER BY table_name;
    table_name
------------------
 bf_fail3_partial
 bf_fail3_valid
(2 rows)

SELECT id, amount FROM bf_fail3_valid ORDER BY id;
 id | amount
----+--------
  1 |     42
(1 row)
```

### Result
The incompatible conversion returned a controlled error and the later valid row `(1, 42)` committed, but the independently read schema still contained `bf_fail3_partial` after `ROLLBACK`. This is concrete runtime evidence of the reported partial-object defect and provides the rollback contract and code path needed to debug it.