Match ID string literal bytes without encoding conflicts

[OskarEichler]

Summary

Match the literal-selection regexp against a binary view of ID strings. Matching its high-byte range directly against UTF-8 raises Encoding::CompatibilityError before ClientID can send ordinary non-ASCII names or values. Preserve the original bytes and the existing quoted-versus-literal policy.

Reproduction

require 'net/imap'
value = Net::IMAP::StringFormatter.string('日本語')
p [value.class, value.data.bytesize] # [Net::IMAP::Literal, 9]
# Before: Encoding::CompatibilityError.

Verification

• 92 focused checks; 22 failing expectations before, zero afterward. UTF-8, ISO-8859-1, binary and invalid UTF-8 byte strings, frozen/mutable inputs, ASCII quoting, CR/LF, nil and symbols, plus ClientID key/value formatting are covered.
• Existing rake test on this isolated branch: 1726 tests, 12594 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications, Ruby 4.0.6 via rbenv. The baseline also passes all 1,726 tests; assertion counts vary slightly across runs.
• Supplemental RuboCop Lint retains the same 48 existing findings. Ruby syntax and git diff --check pass. No repository tests, dependencies or workflows were added or modified; focused reproductions live outside the repository under the consumer's no-new-tests policy.
• Independent branch based on 6d2ef7a636a1e2449187a83b06ac7a5baa54ead2; the runtime diff from released 0.6.6 is documentation-only before this patch.

Compatibility and limits

No signature or wire-format change for previously working input. Non-ASCII strings are sent as literals without transcoding. This is a formatting fix, not a change to charset negotiation or ID input validation. Other Ruby/OS versions were not run locally. No production or external IMAP service was used. Local verification does not imply upstream CI approval or comprehensive behavioral coverage.