[gh-bot-collate]

Automated backport of #37208 to 2.0.

Source PR	#37208
Author	@Vishnuujain
Merge commit	db9448214a23efe71e5bb6f4e00906b760dbd65b
Method	Conflicts resolved by Claude — worth a read of the diff.

Resolution notes

Backport notes: PR #37208 → 2.0

Cherry-pick of db9448214a23efe71e5bb6f4e00906b760dbd65b ("Fixes 37207:
search_metadata returns requested lineage as edge ends") onto 2.0.

Conflict

Only openmetadata-mcp/src/main/resources/json/data/mcp/tools.json conflicted,
in the search_metadata tool's fields parameter description. The other three
files touched by the PR (SearchMetadataTool.java,
SearchMetadataCleanTest.java, and the new ADR doc) applied cleanly via the
cherry-pick with no manual changes.

The conflict was a pure textual collision, not a logic conflict: on main,
this same description string was already carrying an unrelated addition (doc
text for parent, childrenCount and metricGroup fields, from a feature not
present on 2.0). That text does not exist on 2.0, so the two sides'
pre-images differed and git couldn't auto-merge the hunk.

Resolution

Took 2.0's existing description text as the base (without the parent /
childrenCount / metricGroup wording, since that feature isn't on this
branch) and applied only this PR's actual edit on top of it:

• Added upstreamLineage to the list of capped "bulk fields".
• Added the new sentence explaining that upstreamLineage edges are returned
  trimmed to fromEntity/pipeline FQN+type, and that get_entity_lineage
  (with upstreamDepth/downstreamDepth/includeColumnLineage/includeSql/
  nextCursor) is how a caller gets full edge detail.

Verified get_entity_lineage and all the parameters/fields referenced in the
new text (upstreamDepth, downstreamDepth, includeColumnLineage,
includeSql, nextCursor) already exist in tools.json on 2.0, so the new
doc text doesn't point at anything absent from this branch.

No conflict markers remain; the JSON structure (bracket/comma placement) is
intact — I read the surrounding lines after editing to confirm.

For the reviewer

• The resolved description text differs from main's equivalent string only in
  that it lacks the parent/childrenCount/metricGroup wording (correctly
  out of scope here) and lacks parent, metricGroup in the "References" list
  for the same reason. Everything else matches main's intent for this PR.
• The new ADR doc (docs/decisions/2026-11-06-search-metadata-returns-requested-lineage-as-edge-ends.md)
  references a sibling ADR, ADR:2026-10-29-search-metadata-hits-show-their-place-in-a-hierarchy,
  that does not exist under docs/decisions/ on 2.0. This is a documentation
  cross-reference only (no code/behavior depends on it), so it was left as-is
  rather than edited — flagging it here in case the reviewer wants to drop or
  annotate that line.
• openmetadata-mcp/src/main/resources/json/data/mcp/tools.json is left
  unstaged (still shows as UU from the in-progress cherry-pick) per workflow
  instructions — the next step stages it.

---

Opened from openmetadata-collate, which holds the credentials needed to open a PR here. It merges itself once this branch's required checks pass — no review needed. If a check fails it stays open and the author of #37208 is asked to look.

_{resolver run}