Yeah, I agree. Get rid of that option and let's treat "no value" as "detect automatically".

I think there's a small chance this will be a bit confusing (users may feel compelled to select the right value and be unable to find it, since there isn't as much of a hint that we'll figure it out for them) but we could try adding a caption, or changing the placeholder text, or changing the label to "Force Highlight As", or removing the control from the "Create" form and moving it to the "Edit" form only, or probably some other things if there's confusion.

Code changes look correct to me.

Two minor SQL consistency things:

Although bin/storage adjust will fix it anyway, it's slightly better to include the collation explicitly:

ALTER TABLE {$NAMESPACE}_pastebin.pastebin_paste
  MODIFY language VARCHAR(64) COLLATE {$COLLATE_TEXT};

With the collation included, MySQL will only need to do one table copy to apply the mutation (from non-nullable straight to nullable with the correct collation).

Without the collation, MySQL may (in some configurations) need to do two: this one might make the column nullable but leave it with the wrong (default) collation, and then bin/storage adjust would fix the collation later.

The net effect is the same, but if there are a ton of pastes the migration might be a lot slower if it has to make two stops along the journey.

Second, you should name this migration something.01.something and add a something.02.something (that is, make sure your second migration is alphabetically later than the first one) which makes the data consistent for existing pastes:

UPDATE paste SET language = NULL WHERE language = '';

Then old and new pastes should look the same data-wise, and save us from any weird stuff down the line like "the API says '' for some of them and null for others".