Require search-tool-sourced DCIDs in observation and metadata tool instructions

[keyurva]

Summary

Added a constraint to the observation and metadata tool descriptions stating that variable DCIDs must come from the search tools (search_indicators or search_child_indicators) and must not be guessed, assumed, or constructed from memory.

Updated tool instruction files:

• tools/get_observations.md
• tools/get_child_observations.md
• tools/get_multi_entity_observations.md (also updated the variable_dcid parameter description)
• tools/get_variable_metadata.md

Added the same DCID sourcing rule to skills/data-commons-multi-entity-researcher/SKILL.md, which did not have one. The single-place and child-places researcher skills already state this rule.

Why

server.md and the researcher skills already prohibit guessing DCIDs, but those are delivered at session initialization and via opt-in resource reads respectively. Tool descriptions are always present in the tool schema at the point where the model constructs the variable_dcid argument. Hallucinated DCIDs return empty or wrong results rather than a loud error, so the constraint is stated at the point of use as well.

Scope

Markdown instruction files only. No code or behavior changes.

[gemini-code-assist]

Code Review

This pull request updates several instruction and tool markdown files to explicitly mandate that only DCIDs returned by search tools should be used, preventing the model from guessing or assuming them. The review feedback correctly identifies an inaccuracy in the SKILL.md file, where the instructions suggest that entity DCIDs are returned by tools that actually only return variable DCIDs or accept entity DCIDs as inputs, and provides a suggestion to clarify this rule.

[gemini-code-assist]

The instruction states to only use variable and entity DCIDs returned by search_indicators or get_variable_metadata. However, search_indicators only returns statistical variable (indicator) DCIDs, and get_variable_metadata is an assessment tool that takes entity_dcids as an input parameter rather than returning them. This phrasing could confuse the LLM since it cannot obtain entity DCIDs from these tools. It is better to restrict this rule specifically to variable DCIDs.

Suggested change

	* Only use variable and entity DCIDs returned by `search_indicators` or `get_variable_metadata` - never guess or assume DCIDs.
	* Only use variable DCIDs returned by search_indicators - never guess or assume variable DCIDs.