interactive: let standalone providers compose sibling observations

Add an opt-in InteractiveRelatedProviders interface: a checker served
by /check can declare sibling ObservationProviders the SDK will run
in-process after the primary Collect. The SDK auto-fills any sibling
option tagged AutoFill==AutoFillDiscoveryEntries from the primary's
DiscoverEntries output, mirroring the host's AutoFill wiring so
siblings that work in-host work here too. Results are exposed through
ObservationGetter.GetRelated and ReportContext.Related, unblocking
cross-checker rules (e.g. DANE reading checker-tls probes) on the
standalone /check flow.

checker/types.go

@@ -372,6 +372,21 @@ type CheckerDefinitionProvider interface {
 	Definition() *CheckerDefinition
 }
 
+// InteractiveRelatedProviders is an optional interface an interactive
+// ObservationProvider can co-implement to declare sibling providers whose
+// Collect the SDK runs in-process during /check. Their results are
+// exposed as RelatedObservations on ObservationGetter and ReportContext,
+// mirroring the cross-checker lineage a happyDomain host resolves.
+//
+// For each sibling the SDK seeds options from the primary and, when the
+// primary implements DiscoveryPublisher, writes its entries into any
+// sibling option tagged AutoFill == AutoFillDiscoveryEntries. Sibling
+// errors are logged and skipped so the primary result still reaches the
+// user.
+type InteractiveRelatedProviders interface {
+	RelatedProviders() []ObservationProvider
+}
+
 // CheckerDefinition is the complete definition of a checker, registered via init().
 type CheckerDefinition struct {
 	ID              string                      `json:"id"`