Does CloudFormation validate AllowedPattern against the supplied parameter value or a trimmed copy at stack execution?

We have a CloudFormation stack with a String parameter that carries a PEM-formatted public key. We added an AllowedPattern constraint (with a ConstraintDescription) so that a value ending in trailing whitespace (space, tab, newline) or containing a carriage return fails parameter validation. The intent is to reject untrimmed keys at deployment time. The constraint is deployed and verified present on the stack.

Read-only testing with ValidateTemplate shows behavior consistent with the validator checking a trimmed copy of the value: with a template whose parameter default is a short marker string and AllowedPattern anchored to match exactly that string (for example \AA\z, matching only the single character A), ValidateTemplate accepts default values of A followed by a newline, A followed by a space, and A followed by a tab, while rejecting an ordinary mismatch and rejecting an internal carriage return under our deployed pattern. ValidateTemplate does not execute a deployment, so it does not establish behavior for a supplied parameter at execution.

The Parameters documentation says that for a String parameter the AllowedPattern "must match the entire parameter value provided", but does not say whether the value is trimmed or normalized before matching, and does not distinguish ValidateTemplate from execution-time validation.

Question: when a stack create, update, or change-set execution supplies a parameter value (not the template default), does CloudFormation validate AllowedPattern against the value exactly as supplied, or against a trimmed/normalized copy? If trimmed, a trailing-whitespace constraint can never fire at execution; confirmation either way lets us decide whether the constraint is a real control or needs replacing (for example with a deploy-time check outside CloudFormation).