[Subtask]: Separate REGEXP static operands, user variables, and parameter markers

### Parent Issue

Primary issue: #25299. Related semantic and charset issues: #25295, #25300, and #25301.

Related implementation: #26907.

### Detail of Subtask

Separate static REGEXP operand compatibility from runtime user-variable and parameter-marker execution semantics.

#### Invariant

REGEXP binding and execution must preserve the MySQL-visible distinction among a statically typed binary operand, a raw literal, a bare user variable, an SQL PREPARE marker, and a COM_STMT binary/BLOB parameter. Subject and pattern roles must be decided independently, and protocol-source behavior must not leak into unrelated prepared consumers.

#### Scope

- Operators and functions: REGEXP/RLIKE, REGEXP_LIKE, REGEXP_INSTR, REGEXP_SUBSTR, and REGEXP_REPLACE across every supported arity.
- Static inputs: text, _binary literals, BINARY, VARBINARY, BLOB, explicit casts, raw binary literals, ordinary NULL, and typed NULL.
- Dynamic inputs: bare user variables, SQL PREPARE markers, COM_STMT string and BLOB markers, and repeated execution with BLOB-to-string-to-BLOB transitions.
- Subject/pattern combinations: text/text, binary/text, text/binary, and binary/binary, including invalid UTF-8 and position/occurrence arguments.

#### Acceptance criteria

- [ ] Binder acceptance/rejection has an independent matrix from runtime byte/text execution.
- [ ] Subject and pattern source categories are tested independently rather than through one shared IsBin shortcut.
- [ ] SQL PREPARE and COM_STMT are allowed to differ only where the MySQL compatibility oracle requires it.
- [ ] Reuse tests prove BLOB-to-string-to-BLOB behavior is equivalent to fresh statements.
- [ ] Every arity has boundary tests for multibyte text, invalid bytes, NULL, position, occurrence, and replacement output.
- [ ] A real COM_STMT client test validates protocol type metadata; SQL-only tests are not used as a substitute.
- [ ] REGEXP changes do not alter numeric, BIT, JSON, or non-REGEXP prepared-parameter conversions.

#### Out of scope

General provenance transport and ordinary non-REGEXP string functions are owned by separate subtasks.

### Describe implementation you've considered

Represent user-variable and binary-protocol sources explicitly, keep binder item classification separate from runtime encoding choice, and let each REGEXP argument role select its documented policy.

### Additional information

The exact-head review of #26907 exposed distinct failures for static BLOB/BINARY operands, bare binary user variables, SQL PREPARE, and COM_STMT BLOB parameters. They are grouped here because they share one REGEXP source-category invariant, not merely one symptom.