[Copilot] Verify and implement spector tests for 15 scenario groups

[JialinHuang803]

Task: Verify and Implement Spector Integration Tests

Use the spector-test-implementer skill to verify and implement test files for the following not-implemented scenario groups.
Not-implemented scenario groups:

• Azure_ClientGenerator_Core_ClientDefaultValue (1 scenarios: getHeaderParameter)
• Azure_Core_Page (1 scenarios: withParameterizedNextLink)
• Client_Structure (4 scenarios: AnotherClientOperationGroup, ClientOperationGroup, RenamedOperation, TwoOperationGroup)
• Service_MultipleServices_ServiceA_Operations (1 scenarios: opA)
• Service_MultipleServices_ServiceA_SubNamespace (1 scenarios: subOpA)
• Service_MultipleServices_ServiceB_Operations (1 scenarios: opB)
• Service_MultipleServices_ServiceB_SubNamespace (1 scenarios: subOpB)
• Documentation_Lists (3 scenarios: bulletPointsModel, bulletPointsOp, numbered)
• Documentation_TextFormatting (3 scenarios: boldText, combinedFormatting, italicText)
• Payload_JsonMergePatch (3 scenarios: createResource, updateOptionalResource, updateResource)
• Payload_MultiPart_FormData (9 scenarios: anonymousModel, basic, binaryArrayParts, checkFileNameAndContentType, fileArrayAndBasic, jsonPart, multiBinaryParts, optionalParts, withWireName)
• Payload_MultiPart_FormData_File (3 scenarios: uploadFileArray, uploadFileRequiredFilename, uploadFileSpecificContentType)
• Payload_MultiPart_FormData_HttpParts (1 scenarios: jsonArrayAndFileArray)
• Payload_MultiPart_FormData_HttpParts_ContentType (3 scenarios: imageJpegContentType, optionalContentType, requiredContentType)
• Payload_MultiPart_FormData_HttpParts_NonString (1 scenarios: float)
  Instructions:

1. For each scenario group above, check if a .spec.ts file already exists in packages/typespec-ts/test/azureModularIntegration/ — skip if it does
2. For remaining groups, follow the spector-test-implementer workflow to generate the client and verify the generated code is valid before writing tests
3. Read the .tsp and mockapi.ts files carefully to understand the expected behavior before implementing each test
4. Run each test and remove any failing test cases that are due to emitter limitations — only commit passing tests
5. Report which tests passed and which were removed due to failures
   PR description format:
   The PR description must use this format for each section:

New spec files

For each newly created .spec.ts file, use this structure:

• Scenario_Group_Name — scenarioGroupName.spec.ts
  • ✅ scenarioName1
  • ✅ scenarioName2
  • ❌ scenarioName3 (reason for failure)

Updated existing spec files

Same structure as above, but for spec files that already existed and were updated with new scenarios.

Known skips / emitter limitations

List any scenarios that were skipped due to emitter bugs or limitations, with the reason.

Results should be commented on issue #3883.