Fix StepFunctions parser: startExecution parameter/response casing (Pascal to boto)

[Rishi943]

Fixes #10076

The arn:aws:states:::states:startExecution(.sync|.sync:2) service integration (a state machine starting another state machine) failed under the parser backend with States.Runtime / KeyError: 'Input'.

Root cause: the ASL Parameters use the Pascal-cased Step Functions API member names (StateMachineArn, Input, Name, TraceHeader), but these were passed straight to boto3's start_execution, whose members are lowerCamel (stateMachineArn, input, name, traceHeader). Unlike sibling service integrations (SNS, SQS, DynamoDB) whose boto3 members are already Pascal-cased and pass through the ASL Parameters unchanged, Step Functions' own API uses lowerCamel, so this integration needs explicit normalisation — the generic _to_boto_request/_from_boto_response helpers on the base StateTaskService existed but were never invoked for this path.

This PR wires up those existing helpers in StateTaskServiceSfn, looking up the real botocore service model shapes for StartExecution/DescribeExecution, to convert:

• request parameters: ASL PascalCase -> boto3 lowerCamel, before the call
• response: boto3 lowerCamel -> ASL PascalCase, for both the immediate start_execution output and the .sync/.sync:2 describe_execution output used by the sync resolvers

This mirrors the sibling service-integration casing pattern (e.g. SQS's _normalise_response already renames Md5OfMessageBody -> MD5OfMessageBody), extended here to cover the full request/response shape since Step Functions' own casing differs across every member, not just one.

Test plan:

• Added tests/test_stepfunctions/parser/test_stepfunctions_sfn_integration.py: regression tests on _normalise_parameters/_normalise_response (request casing for .sync:2 and plain startExecution, response casing for start_execution and describe_execution outputs), verified failing on main and passing with this change.
• Ran tests/test_stepfunctions/parser (excluding docker-requiring tests): no new failures introduced.
• A full end-to-end parent->child .sync:2 test currently cannot reach SUCCEEDED regardless of this fix because of the separate deepcopy/RLock bug tracked in StepFunctions parser: second StartExecution on the same state machine fails with 'cannot pickle _thread.RLock' (deepcopy of executions) #10077 (with this fix, the failure changes from KeyError: 'Input' to that unrelated pickle error), so the committed regression tests target the normalisation layer directly.

[codecov]

Codecov Report

❌ Patch coverage is 96.15385% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 93.29%. Comparing base (42808d7) to head (63e980f).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
.../exec/state_task/service/state_task_service_sfn.py	96.15%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10101      +/-   ##
==========================================
+ Coverage   93.24%   93.29%   +0.04%     
==========================================
  Files        1326     1326              
  Lines      120997   121016      +19     
==========================================
+ Hits       112825   112897      +72     
+ Misses       8172     8119      -53     

Flag	Coverage Δ
servertests	29.54% <96.15%> (+1.58%)	⬆️
unittests	93.26% <96.15%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.