test: characterize Client#parse handling of inline named fragments

[rellampec]

Pin current behavior of locally-defined named fragments (a 'fragment Name on Type' spread via '...Name' within the same document), transitive local fragments, and the source_document vs sliced document distinction. These were only exercised incidentally alongside constant-path spreads; isolating them guards a future refactor of the fragment-resolution step in parse.

What this does

Adds characterization tests that pin the current behaviour of Client#parse when a document contains an inline
named fragment — a fragment Name on Type { … } definition spread via ...Name from within the same parse string
(as opposed to a fragment bound to a Ruby constant).

New file: test/test_parse_fragment_characterization.rb — 3 tests / 18 assertions, Minitest, passing.

It pins three behaviours that are currently exercised only incidentally:

1. Local resolution without a constant — a ...Name spread referring to a fragment defined in the same document
   (with no matching Ruby constant) is resolved locally: the definition is kept and renamed with the document's constant
   path, the spread is rewritten to the renamed name, and no ValidationError is raised.
2. Transitive local fragments — a local fragment that itself spreads another local fragment resolves the whole
   chain, and the operation's sliced document carries the full transitive dependency set.
3. source_document vs sliced document — for a multi-operation document, each operation's document is sliced
   to just that operation + its own fragment dependencies, while source_document retains every sibling definition.

Why

This is test-only — no behaviour change. It's a safety net placed before a follow-up that will tighten fragment-spread matching in Client#parse.

Today the spread/definition detection uses an unanchored str.match(/fragment\s*#{const_name}/), which can misfire on prefix collisions (e.g. ...UserFields matching fragment UserFieldsExtended) and even on fragmentUserFields. A planned change will anchor that to fragment\s+Name\s+on\b. Pinning the surrounding behaviour first means that refactor can't silently change any of the guarantees above.

Worth noting: an earlier attempt to "improve spread constant matching" was reverted (b5a4612), so characterizing the current behaviour before touching it again seemed prudent.

Relationship to other PRs

• Demonstrates the behaviour documented in docs: document inline (colocated) named fragments #80 (inline / colocated named fragments) and motivated by Would it be possible to use Fragments just for pure re-usability? (without forced parent-child component encapsulation) #76.
• Independent of docs: add CHANGELOG and CONTRIBUTING #79/docs: document inline (colocated) named fragments #80 — branches off master, clean diff.
• Lays the groundwork for the parse-robustness fix that will follow; Would it be possible to use Fragments just for pure re-usability? (without forced parent-child component encapsulation) #76 stays open until that lands.