Ref T1191. Currently if a developer forgot to specify a column type, storage adjust aborts explosively mid-stream. Instead:

• Make this a formal error with an unambiugous name/description instead of something you sort of infer by seeing "<unknown>".
• Make this error prevent generation of adjustment warnings, so we don't try to ALTER TABLE t CHANGE COLUMN c <unknown>, which is nonsense.
• When schemata errors exist, surface them prominiently in storage adjust.

Overall:

• Once storage upgrade runs storage adjust automatically (soon), this will make it relatively difficult to miss these errors.
• Letting these errors slip through no longer escalates into a more severe issue.

Commented out the recent mailKey spec and ran storage adjust:

$ ./bin/storage adjust --force 
Verifying database schemata...
Found no adjustments for schemata.

Target                                            Error                      
phabricator2_phriction.phriction_document.mailKey Column Has No Specification

 SCHEMATA ERRORS 

The schemata have serious errors (detailed above) which the adjustment
workflow can not fix.

If you are not developing Phabricator itself, report this issue to the
upstream.

If you are developing Phabricator, these errors usually indicate that your
schema specifications do not agree with the schemata your code actually
builds.