Discovery: Add Beacon data as additional discovery mechanism

[bburda]

Summary

Beacon is an optional mechanism where Apps announce runtime hints to make discovery more accurate without requiring a full Manifest.

Examples of hints:

• App identity and stable ID binding
• Function membership
• Dependencies
• Extra metadata useful for diagnostics UX

Beacon is valuable for dynamic systems (nodes joining mid-session, OTA updates), but it is also requires changes in the whole system.

---

Proposed solution (optional)

Implement Beacon as an enrichment provider that plugs into the merge pipeline:

• Choose a Beacon transport (topic publication or parameter based, or both)
• Define a small Beacon message format
• Define TTL and expiry rules if using topic based announcements
• Define polling strategy if using parameters
• Merge rules should never redefine structure, only enrich declared or discovered entities

[bburda]

Update: NITROS transport detection as first concrete use case

Now that the plugin infrastructure is in place (#235/#246), Beacon can be implemented as a standard enrichment plugin in the merge pipeline.

A concrete use case emerged from the x-medkit-graph discussion (#248): NITROS transport detection. The transport_type field in the graph schema (nitros_zero_copy, shared_memory, intra_process, etc.) can't be populated from outside - standard ROS 2 APIs don't expose transport negotiation results, and the data lives inside the NITROS process.

Beacon solves this naturally. A NITROS node knows what it negotiated - it just needs to announce it:

Beacon hint:
- transport_type: "nitros_zero_copy"
- negotiated_format: "nitros_image_bgr8"
- gxf_entity_status: "STARTED"

This is push-based (app → gateway), which is the right model for data that only the app has:

• Transport type and negotiated format
• Function membership and dependencies
• Custom metadata for diagnostics UX

The three-plugin picture:

Plugin	Model	Data
#112 Introspection	Pull (gateway → platform)	Process mapping, systemd, containers
#111 Beacon	Push (app → gateway)	Transport type, negotiated format, dependencies
#248 Graph	Serve (gateway → client)	DAG topology + metrics, consumes from both above

No upstream NVIDIA feature request needed - we define the Beacon message format, NITROS nodes publish it. Other platforms can use the same mechanism.