feat(core): add --related-to flag to ado get for filtering by anchor resource type

[AlessandroPomponio]

Summary

Adds a --related-to flag to ado get that filters listed resources by their relationship to a given anchor resource (e.g. "show all operations linked to this sample store"). This makes it easy to navigate the resource graph without knowing individual identifiers upfront.

High-level Changes

• New --related-to flag on ado get: accepts a kind=id pair (e.g. samplestore=store-abc123) and filters results to resources reachable from that anchor; shorthand aliases (e.g. store=) are supported.
• Tests: added a comprehensive new test suite covering all metastore resource types, invalid flag combinations, and error paths.
• Documentation: updated CLI reference with flag description, constraints, and usage examples; updated query-ado-data and using-ado-cli skills accordingly.

Impact

Users can now filter ado get results by relationship to another resource directly from the CLI, removing the need for manual cross-referencing. The change is purely additive and has no impact on existing commands or behaviour.

---

AI Disclosure: The code and this PR description were generated using IBM Bob and reviewed manually.

[michael-johnston]

implementation looks good except for excluding the ability to filter on same kind (see comment).

Terminology in docs is not consistent: we have "related", "reachable", "linked" and use the term "anchor" which seems to give no additional meaning c.f.

"related to given resource" to "related to given anchor resource" - what does anchor tell me?

[michael-johnston]

Suggested change

	# All spaces related to a sample store (name only)
	# All spaces related to a sample store (name only) using short name

[AlessandroPomponio]

It's probably more worth it to write samplestore in L222 rather than adding 3 words in a skill

[michael-johnston]

As you like 👍

[michael-johnston]

I suggest using a term along the following lines to refer to the allowed multi-hop relationships

1. Depth & Graph-Oriented Terms

These terms focus on the fact that you are limiting the traversal depth of the tree/graph.

First-Order Hierarchy: Clearly communicates that you are only dealing with the primary, immediate relationships, not second-order recursive ones.
Level-1 Subgraph (or L1 Subgraph): A graph theory term that implies you are looking at a specific, restricted slice of the overall resource graph.
Shallow Resource Tree: Contrasts perfectly with "deep" or recursive searches.

2. Search & Boundary-Oriented Terms

These terms are great if the primary use case is defining the scope for your search function.

Base (or Core) Search Envelope: "Envelope" perfectly captures the idea of a defined boundary that contains specific things but stops at a certain edge.
Core Resource Context: Implies that this set of relationships forms the foundational context for a resource, without getting into the weeds of extended lineage.
Primary Search Boundary: Very explicit about what the term is used for.

e.g.

Suggested change

	Filter `ado get` results to resources related to a specific source resource,
	including multi-hop relationships (e.g. operations linked to a space that is
	linked to a store). Specify the source as `kind=id` (shorthand aliases supported):
	Filter `ado get` results to resources related to a specific source resource,
	within the core resource search hierarchy. Specify the source as `kind=id` (shorthand aliases supported):

[AlessandroPomponio]

I think these are very complex terms that require very specific knowledge and might actually hinder general comprehension of what we're doing.

If I ask Bob "what is the hierarchy between ado resources top-to-bottom", it creates this diagram:

graph TD
    SS["<b>SampleStore</b><br/><sub>samplestore</sub><br/>Persistent storage for entity measurements"]
    AC["<b>ActuatorConfiguration</b><br/><sub>actuatorconfiguration</sub><br/>Parameters for a specific actuator"]
    DS["<b>DiscoverySpace</b><br/><sub>discoveryspace</sub><br/>Entity + measurement space"]
    OP["<b>Operation</b><br/><sub>operation</sub><br/>Runs an operator on a DiscoverySpace"]
    DC["<b>DataContainer</b><br/><sub>datacontainer</sub><br/>Output data produced by an operation"]

    SS -->|"sampleStoreIdentifier (1)"| DS
    SS -->|"copyFrom[] (0..*)"| SS
    AC -->|"actuatorConfigurationIdentifiers[] (0..*)"| OP
    DS -->|"spaces[] (1)"| OP
    OP -->|"OperationOutput.resources (0..*)"| DC
    OP -->|"writes measurements back"| SS

Loading

Which I assume is what people will most likely think of, and I would refer to this as simply "the hierarchy". Beyond the hierarchy, I would refer to all possible relationships between resources as "the graph". I would however avoid going too mathematical or technical with the terms for the sake of general understanding