Integrity check compares a cast-stripped default against the raw one — every converged migrate exits non-zero

[MelbourneDeveloper]

Version

DataProviderMigrate 0.9.12-beta.

Summary

The post-apply schema integrity check reports a mismatch between a default and
itself, differing only by the ::text cast:

Migration completed successfully
SCHEMA INTEGRITY CHECK FAILED
public.topup.status: default expected 'pending' but found 'pending'::text

The schema declares exactly what the database contains:

- name: status
  type: Text
  isNullable: false
  defaultValue: "'pending'::text"

One side of the comparison is normalised (cast stripped) and the other is not, so
they can never match for any defaultValue written with an explicit cast.

Impact

This is worse than cosmetic, because it destroys the exit code as a signal:

Phase: all — applying 1 of 1 operation(s):
  AddCheckConstraintOperation
Migration completed successfully
SCHEMA INTEGRITY CHECK FAILED
make: *** [migrate] Error 1

The migration applied correctly and the tool still exits non-zero. A fully converged
database does the same:

Schema is up to date — no operations needed
SCHEMA INTEGRITY CHECK FAILED

So an operator cannot distinguish "your migration failed" from "your migration worked
and the checker is comparing a string to itself", and no wrapper can gate on the exit
status. We hit this while diagnosing a real failure (#96) and had to read the log body
to tell the two apart.

Expected

Normalise both sides before comparing — parse the default to a value, or apply the
same cast-stripping to the value read from pg_attrdef that is applied to the schema
value. A converged database should exit 0.