Discovery: Implement merge pipeline for discovery hybrid approach

[bburda]

Summary

We need a clear merge strategy so that multiple discovery inputs can coexist without becoming separate modes.

Target behavior:

• Manifest is the source of truth when present
• Runtime signals can enrich Manifest (metadata, runtime grouping, dependencies)
• Heuristics can fill gaps when Manifest is absent or incomplete
• Beacon can be added later as another enrichment source that plugs into the same pipeline

---

Proposed solution (optional)

• Implement a merge pipeline with explicit precedence rules:
  • Base layer: Manifest (if present)
  • Enrichment: runtime derived metadata (process grouping, live presence)
  • Gap fill: heuristics for undeclared entities when allowed
• Define conflict resolution rules (ID collisions, duplicate entities, inconsistent mapping).
• Make the pipeline extensible so Beacon can later plug in as an enrichment provider.

[bburda]

Current Implementation Status:

Already Implemented:

• Manifest priority: HybridDiscoveryStrategy uses manifest as source of truth when present
• Runtime enrichment: Apps and components get runtime data (topics, services, actions) via RuntimeLinker
• Heuristic fallback: Falls back to RuntimeDiscoveryStrategy when no manifest
• Orphan handling: UnmanifestedNodePolicy for nodes not in manifest (IGNORE/WARN/ERROR/INCLUDE_AS_ORPHAN)

Remaining Work:

1. Formal merge pipeline architecture

   • Current: Ad-hoc merging in discover_components() and RuntimeLinker::link()
   • Needed: Unified MergePipeline class with explicit layers and precedence

2. Conflict resolution rules

   • ID collisions between sources (manifest defines sensor_a, runtime discovers sensor_a)
   • Duplicate entity detection and deduplication strategy
   • Inconsistent metadata merge strategy (which source wins for each field?)

3. Extensible enrichment interface

   • Define EnrichmentProvider interface for pluggable sources
   • Register/unregister providers at runtime
   • This enables Beacon integration later without modifying core code

4. Configurable gap-fill policy

   • Per-entity-type control: e.g., allow heuristic components but not operations
   • Whitelist/blacklist patterns for what heuristics can create

5. Enhanced runtime metadata

   • Process grouping (nodes in same process)
   • Live presence beyond is_online flag (last seen timestamp, health status)
   • Dependency inference (topic connections between entities)