[Extensibility Request][Quality Management] No supported way to create inspections through the rule engine; all creation procedures are internal

Describe the issue

There is no supported way for a partner extension to ask Quality Management to "create an inspection for this record through the rule engine" with automatic-creation semantics. Every procedure involved in the app's own automatic creation flow is internal, and the manifest grants internalsVisibleTo only to Microsoft's Quality Management Test Library (src/Apps/W1/Quality Management/app/app.json:33).

Compiling a minimal extension against the shipped 28.3 symbols that reproduces the app's own receiving flow yields nine AL0161 protection-level errors, one per call. On current main the procedures are:

• "Qlty. Inspection - Create": CreateInspectionWithMultiVariants (QltyInspectionCreate.Codeunit.al:154), GetCreatedInspection (:781), IsLastInspectionNewlyCreated (:807). In fact every creation procedure in this codeunit is internal.
• "Qlty. Warehouse Integration": CollectSourceItemTracking (QltyWarehouseIntegration.Codeunit.al:131)
• "Qlty. Batch Notif. Helper": BeginBatch (:15), EndBatch (:21), TrackCreatedInspection (:36), ConfigureForBatch (:51)
• "Qlty. Management Setup": GetSetupRecord (QltyManagementSetup.Table.al:527)

The two accessible entry points do not substitute for automatic generation, because both hard-code IsManualCreation = true:

• API page QltyCreateInspectionAPI.Page.al:94 and :131 call CreateInspection(AnyInputRecord, true)
• Report QltyCreateInspection.Report.al:326 calls CreateInspectionWithMultiVariantsAndTemplate(..., true, ...)

Manual creation applies the manual activation filter, ignores the per-source trigger fields, can open the inspection card, and raises a hard error when no rule matches. None of that is acceptable inside an automatic flow such as an event subscriber on a posting or document-creation routine.

The published integration events do not help either: each one is raised only from inside a path the app has already entered (purchase receipt, warehouse receipt from purchase, transfer posting, sales return posting). They allow modifying or replacing behavior at the moments the product ships, but cannot add a trigger moment the product does not ship.

Concrete consequence: to create inspections at warehouse receipt creation for transfer-sourced receipt lines (#9977), an extension currently has to re-implement rule matching, source field mapping, duplicate detection, and template expansion outside the app. That re-implementation drifts from the product on every update. This request stays relevant even if #9977 is fixed, because any next missing trigger moment hits the same wall.

Expected behavior

Either a public, supported entry point on "Qlty. Inspection - Create" (or a facade codeunit) that creates an inspection for a given record through the rule engine with non-manual semantics and returns the created inspection, or widened access (public) on the procedures listed above.

Steps to reproduce

1. Create an AL extension depending on Quality Management.
2. In a codeunit, declare QltyInspectionCreate: Codeunit "Qlty. Inspection - Create" and call CreateInspectionWithMultiVariants(...).
3. Compilation fails with AL0161: cannot access internal procedure. The same happens for the other procedures listed above.

Additional context

The pattern of the ask matches how other first-party apps expose their engines for extension scenarios. A single public procedure with the semantics "find matching generation rules for this record and create or reuse an inspection, non-manual, no UI" would cover the need; the batch notification helper and tracking collection only need to be public if the entry point does not handle them internally. A sketch of what would be sufficient, on "Qlty. Inspection - Create" or a small public facade codeunit:

/// <summary>
/// Creates or reuses a quality inspection for the given record by matching the active
/// inspection generation rules, using automatic-creation semantics: no UI, the manual
/// activation filter is not applied, and no error is raised when no rule matches.
/// </summary>
/// <param name="RecordVariant">The record to create the inspection for.</param>
/// <param name="OptionalRelatedRecordVariant">Optional related record (for example a source document line) used for rule matching and source field mapping.</param>
/// <param name="QltyInspectionHeader">The created or reused inspection.</param>
/// <param name="IsNewlyCreated">True when the inspection was newly created rather than reused.</param>
/// <returns>True when an inspection was created or reused.</returns>
procedure CreateInspectionFromRuleEngine(RecordVariant: Variant; OptionalRelatedRecordVariant: Variant; var QltyInspectionHeader: Record "Qlty. Inspection Header"; var IsNewlyCreated: Boolean): Boolean

Item tracking handling could either be internal to the entry point (collect from the source and create one inspection per tracking line, matching the app's own receiving flow) or covered by an overload accepting a Tracking Specification buffer. Alternatively, simply widening access on the nine procedures listed above unblocks the scenario with no new surface, at the cost of exposing more implementation detail.

I will provide a fix for a bug

• I will provide a fix for a bug