MASTER_DEMOTE_TO_SLAVE is rejected as an unquoted column identifier

MariaDB 12.3.3-MariaDB-ubu2404 on Linux x86_64 rejects `master_demote_to_slave` as an unquoted column identifier with ERROR 1064. The neighboring replication-option keyword `master_use_gtid` works unquoted, while quoting `master_demote_to_slave` also works.

Reproducer

Run this setup first:

DROP DATABASE IF EXISTS parser_test;

CREATE DATABASE parser_test;

USE parser_test;

CREATE TABLE control_keyword (master_use_gtid INT);

INSERT INTO control_keyword VALUES (7);

SELECT master_use_gtid FROM control_keyword;

SELECT WORD FROM INFORMATION_SCHEMA.KEYWORDS

WHERE WORD IN ('MASTER_USE_GTID',

               'MASTER_DEMOTE_TO_SLAVE',

               'MASTER_DEMOTE_TO_REPLICA')

ORDER BY WORD;

The control query returns 7, and all three keyword spellings appear in `INFORMATION_SCHEMA.KEYWORDS`.

Then run the failing statement:

USE parser_test;

CREATE TABLE candidate_keyword (master_demote_to_slave INT);

Observed behavior

The unquoted candidate is rejected:

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'master_demote_to_slave INT)' at line 1

The same spelling succeeds when quoted:

USE parser_test;

CREATE TABLE quoted_keyword (`master_demote_to_slave` INT);

INSERT INTO quoted_keyword VALUES (11);

SELECT `master_demote_to_slave` FROM quoted_keyword;

This returns:

master_demote_to_slave

11

Expected behavior

`master_demote_to_slave` should be accepted as an unquoted identifier in this context, like the neighboring `master_use_gtid` token. The successful quoted form confirms that the identifier spelling itself is valid; rejection only in the unquoted form indicates that the token is assigned the wrong identifier-reservedness category.

This occurs when MASTER_DEMOTE_TO_SLAVE is used as an unquoted identifier, such as a column name.