fix: pass original value to ParseTypeError in ArrayParameter and MapParameter

[he-yufeng]

In Go, a two-result type assertion like x, ok := v.(T) sets x to the zero value of T when the assertion fails — nil for slice and map types. Both ArrayParameter.Parse and MapParameter.Parse were passing this zero value to ParseTypeError instead of the original argument v, so a caller would see an error like:

<nil> not type "array"

instead of something useful that identifies what was actually passed in.

The five other Parse methods in the same file — StringParameter, IntParameter, FloatParameter, BoolParameter, and the integer sub-case — all correctly pass v to ParseTypeError. This PR brings ArrayParameter and MapParameter in line with that pattern.

Changed lines:

// Before
return nil, &ParseTypeError{p.Name, p.Type, arrVal}  // arrVal is nil on failed assertion
return nil, &ParseTypeError{p.Name, p.Type, m}        // m is nil on failed assertion

// After
return nil, &ParseTypeError{p.Name, p.Type, v}
return nil, &ParseTypeError{p.Name, p.Type, v}

Two regression tests are added in TestParseTypeErrorIncludesValue: one for ArrayParameter.Parse("not-an-array") and one for MapParameter.Parse("bad"), each asserting the error message contains the original input value. Both tests fail before this fix and pass after.

[gemini-code-assist]

Code Review

This pull request fixes a bug in ArrayParameter.Parse and MapParameter.Parse where a type assertion failure resulted in ParseTypeError reporting a nil value instead of the original invalid input value. The fix correctly passes the original input v to ParseTypeError. Additionally, a new unit test TestParseTypeErrorIncludesValue has been added to verify this behavior. I have no feedback to provide.

[he-yufeng]

Closing in favor of #3512, which lands the same fix (passing the original v to ParseTypeError in ArrayParameter.Parse and MapParameter.Parse instead of the nil asserted variable) with a tidier table-driven test. No point keeping two open PRs for the same bug.