[BugFix] Fix type mismatch in map literal when explicit key/value types are declared (backport #71316) (backport #71345)

[mergify]

Why I'm doing:

Fix https://github.com/StarRocks/StarRocksTest/issues/11202

When a map literal is written with an explicit type annotation (e.g., map<smallint, smallint>{1: 2, 3: 4}), the FE analyzer failed to cast the child expressions (key/value literals) to the declared key and value types.
Integer literals like 1, 2, 3, 4 are inferred as TINYINT by default. Because visitMapExpr only handled the implicit-type case (AnyMapType.ANY_MAP) and had no logic for the explicit-type case, the children retained their inferred TINYINT types. These mistyped expressions were then serialized and sent to the BE.
On the BE side, MapExpr::evaluate_checked cloned the key column as a FixedLengthColumn<int8_t> (1 byte), but later attempted to append it into a FixedLengthColumnBase<int16_t> (2 bytes), causing a heap-buffer-overflow detected by
AddressSanitizer.

A typical reproducer:

  ALTER TABLE t ADD COLUMN c MAP<SMALLINT, SMALLINT>
  DEFAULT map<smallint, smallint>{1: 2, 3: 4};                                                                                                                                                                                          
                                              
  SELECT id, c FROM t ORDER BY id;  -- crashes BE       

Root Cause

In ExpressionAnalyzer.visitMapExpr, when the map has an explicit MapType (not AnyMapType.ANY_MAP), no casting was applied to the child expressions. The declared key/value types were simply ignored, and children kept their own inferred types.

The same issue did not exist for ArrayExpr — visitArrayExpr already correctly casts children to the declared item type when an explicit array type is present.

Fix

When the map literal has an explicit type, extract the declared keyType and valueType from the MapType and cast each key/value child expression to the corresponding type if it doesn't already match — exactly mirroring the existing pattern in visitArrayExpr.

What I'm doing:

Fix type mismatch in map literal when explicit key/value types are declared

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5
  • 3.4

---

This is an automatic backport of pull request #71316 done by [Mergify](https://mergify.com).

---

This is an automatic backport of pull request #71345 done by [Mergify](https://mergify.com).