Merge: convergent ADD COLUMN flagged as conflict, silently drops DML

## Summary
When two branches each run an identical \`ALTER TABLE ... ADD COLUMN\` with the same name/type/default, Dolt flags the merge as having 1 schema conflict, and under autocommit rolls back (per #5-something, the autocommit-conflict rollback). Result: the side-branch's DML on that new column is silently lost.

This is surprising because the schema changes are textually identical — convergent DDL should merge cleanly, not conflict.

Tested against Dolt 1.86.3.

## Minimal repro
```sql
CREATE TABLE t(id INTEGER PRIMARY KEY, v TEXT);
INSERT INTO t VALUES(1,'a');
CALL dolt_add('-A');
CALL dolt_commit('-m','base');

CALL dolt_checkout('-b','feat');
ALTER TABLE t ADD COLUMN extra INTEGER DEFAULT 0;
UPDATE t SET extra=11 WHERE id=1;
CALL dolt_add('-A');
CALL dolt_commit('-m','feat');

CALL dolt_checkout('main');
ALTER TABLE t ADD COLUMN extra INTEGER DEFAULT 0;
INSERT INTO t VALUES(2,'b',22);
CALL dolt_add('-A');
CALL dolt_commit('-m','main');

CALL dolt_merge('feat');
SELECT id, v, extra FROM t ORDER BY id;
```

### Observed (Dolt 1.86.3)
```
hash,fast_forward,conflicts,message
"",0,1,conflicts found
error on line 15 for query CALL dolt_merge('feat'): Merge conflict detected, @autocommit transaction rolled back. ...

id,v,extra
1,a,0
2,b,22
```
The merge is refused. Feat's \`UPDATE t SET extra=11 WHERE id=1\` is gone — id=1 shows the default \`0\` instead of \`11\`.

### Expected
Identical \`ADD COLUMN ... DEFAULT 0\` on both sides should merge cleanly, preserving each side's independent row changes:
```
id,v,extra
1,a,11
2,b,22
```
(This is what doltlite produces.)

## Analysis / speculation
My guess is the conflict detector is treating \`ADD COLUMN ... DEFAULT 0\` as implicitly writing \`0\` to every existing row. Then on main, id=1 has \`extra=0\` from the implicit write; on feat, id=1 has \`extra=11\` from the explicit UPDATE. The detector sees divergent values on id=1 and flags a row conflict. But from a user's perspective, the main side never wrote to id=1's \`extra\` column, only the schema default applied — the feat update should win.

Either the detector should consider default-backfill to be ignorable when the two branches installed the same schema, or convergent DDL should be recognized as a no-conflict case before the row-conflict check runs.

## Surfaced by
Oracle cross-engine parity testing (doltlite vs Dolt). Probe \`both_sides_add_same_col_same_type\` in dolthub/doltlite#572, omitted from the committed suite with an inline \`NOTE\` comment.