fix: anchor inline fragment-definition detection in Client#parse

[rellampec]

The bug

When Client#parse walks ...Name spreads, it decides for each whether Name is a named fragment defined in the same document (leave the spread alone) or a Ruby constant to resolve. That decision used an unanchored match:

str.match(/fragment\s*#{const_name}/)

which matches too eagerly:

• \s* allows zero whitespace (fragmentName matches), and
• there's no boundary after the name, so a ...UserFields spread matches a fragment UserFieldsExtended on User definition.

When that false positive happens, the spread is left unresolved and is never registered as a constant dependency.
Downstream this doesn't just produce a wrong query — it crashes in sliced_definitions with TypeError: no implicit conversion of nil into Array. An earlier attempt to tighten this matching was reverted long ago (b5a4612), so the eager form has been in place since.

The fix

Anchor the match to a real fragment definition:

str.match(/fragment\s+#{Regexp.escape(const_name)}\s+on\b/)

Tests

Adds test/test_parse_fragment_anchoring.rb:

• ...UserFields alongside fragment UserFieldsExtended on User now surfaces a clean uninitialized constant UserFields ValidationError (previously: the TypeError crash above).
• Two prefix-sharing inline fragments (UserFields / UserFieldsExtended), both spread, still resolve locally —
  anchoring isn't over-strict.

No behaviour change to anything pinned by the characterization tests (#81) — they remain green.

Relationship to other PRs

• Builds on test: characterize Client#parse handling of inline named fragments #81 (characterization tests). Until test: characterize Client#parse handling of inline named fragments #81 merges, this PR's diff also shows that test file; it narrows to just lib/graphql/client.rb + test/test_parse_fragment_anchoring.rb once test: characterize Client#parse handling of inline named fragments #81 lands.
• This is the robustness fix referenced in Would it be possible to use Fragments just for pure re-usability? (without forced parent-child component encapsulation) #76 and docs: document inline (colocated) named fragments #80 — with it, the inline/colocated named-fragment path is safe against prefix collisions. Good candidate to ride the next release.