[GAP-10] Apply various improvements/clarifications to @mock spec

[rebello95]

Summary

Fixes spec inconsistencies, tightens language, and cleans up the README FAQ for GAP-10 based on discussions from last week's Working Group Day and this Discord thread.

DRAFT.md

• Fixed ValidateNoNestedMocks logic: isChildrenMocked used AND when it should use OR, preventing the mocked state from propagating to children
• Added clarifying note that "No Empty Operation Root Validation" doesn't apply when @mock is on the operation definition itself
• Clarified error merging semantics: client must append errors to the response array
• Clarified schema language throughout: mocked fields must be defined locally, but need not be deployed on the server
• Removed "fields not defined in the schema are skipped during validation" — validation always runs against the client's local schema, which includes not-yet-deployed types
• Added non-normative note that validation timing (codegen, test suite, on-demand) is implementation-defined

SKILL.md

• Fixed error example to include a variant id wrapper and required __path__ field (was invalid per the DRAFT's mock file structure)
• Added __ prefix constraint to mock variant id creation instructions

README.md

• Removed "Future Proposal" section about random picks from multiple @mock values (contradicts the Order Instability rationale in the same FAQ)
• Removed "New types are unreachable" rationale from the inline fragment "Why not?" section
• Condensed "Why isn't array position supported?" from ~130 lines to a concise numbered list of the three core arguments
• Retitled FAQ sections as questions for consistency
• Clarified schema language to match DRAFT ("defined locally but not yet deployed")
• Other minor cleanups

Please review

@magicmark

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: rebello95 / name: Michael Rebello (1842a2e, 2297b6b, 347d488, 5b20871)

[rebello95]

Open question: I think we probably want the implementer to inject the proper "path" value for each error object at runtime based on the context in which the mock is being used. The alternative would be to have the mock file include the full path in each error, which I think could be odd for fields mocked within fragments. Thoughts?