Output Validation: S9: Additional schema file accessibility for validation #3611

Description:
When a SAFE type override references a type from an additional schema file (uploaded via FieldOverrideService.addSchemaFilesForTypeOverride()), the validator needs access to that file to resolve xsi:type.

The additional file is in definitionFiles and filePath[], but the root schema may not have an xs:import directive for it.

Approach depends on S3i investigation and S8 outcome:

• If JAXP resolves xsi:type types from classpath without explicit import → no wrapper needed
• If not → generate a thin wrapper XSD that xs:imports all schema files from targetBody.filePath[] and use it as the validator's resourceUri
• If S8 already implements schema flattening (because classpath resolution failed for xs:include/xs:import), then additional files that aren't explicitly imported would also need to be included in the flattening — build on S8's infrastructure
• Optimization: only generate wrapper when additional files exist that aren't already imported by the root schema (compare XmlSchemaAnalysisService dependency graph against filePath[])

Key files:

• packages/ui/src/services/document/xml-schema/xml-schema-analysis.service.ts
• New service for wrapper schema generation (if needed)

Expected Outcome:

• If S3i confirms classpath-only resolution works: This issue is a no-op. Document that classpath presence is sufficient for xsi:type resolution and close the issue.
• If S3i reveals explicit import is required: A wrapper schema generator that produces a thin XSD containing xs:import directives for all schema files in targetBody.filePath[]. The wrapper is used as the validator's resourceUri instead of the root schema. Only generated when additional files exist that aren't already imported by the root schema (determined by comparing XmlSchemaAnalysisService dependency graph against filePath[]). Unit tests covering wrapper generation, conditional generation logic, and validation with the wrapper.

Dependencies: S1i, S3i, S4, S8