fix(template): treat invalid expression pattern modifier as literal

[seonwooj0810]

Fixes #2739

Root cause

A header-map value (or any template fragment) such as {test:[abc} is parsed by Expressions.create as a {name:pattern} expression, where the part after : is treated as a regex value modifier. Expression's constructor compiles that modifier eagerly via Pattern.compile(...), so when the modifier is not a valid regular expression ([abc → Unclosed character class) a PatternSyntaxException was thrown during template construction. With a Map header value containing brackets/colons this surfaces as the stack trace in the issue (HeaderTemplate.create → Template → Expressions.create → Pattern.compile).

Change

Expressions.create already returns null to signal "this is not a usable expression — treat the chunk as a literal" (e.g. for nested expressions and non-simple candidates). This extends that existing contract: a PatternSyntaxException raised while building the expression is caught and create returns null, so the fragment falls back to a Literal in Template.parseFragment instead of failing template construction. Valid expressions such as {id:[0-9]+} are unaffected.

Test evidence

Added ExpressionsTest.invalidPatternModifierIsTreatedAsLiteral — Expressions.create("{test:[abc}") previously threw PatternSyntaxException; it now returns null (literal).

Verification done: built and ran the affected tests with the project toolchain — ./mvnw -pl core test -Dtest='feign.template.**' → 80 tests pass (including the new one), no regression; code formatting validated via git-code-format-maven-plugin:validate-code-format (BUILD SUCCESS); commit carries a DCO Signed-off-by trailer.