docs: document inline (colocated) named fragments

[rellampec]

What this does

Documents that standard named GraphQL fragments defined inline — a fragment Name on Type { … } definition placed in the same parse string as the operation that spreads it — are supported, and their fields are directly accessible on the result (no ImplicitlyFetchedFieldError, no re-wrapping through a fragment constant).

This is documentation only — the behaviour already exists in Client#parse (the local fragment definition is kept and the fields flow through source_document); it just wasn't documented anywhere.

Files

• README.md — new "Named fragments defined inline" section, with a note that this follows Apollo Client's colocating fragments convention.
• guides/implicitly-fetched-field-error.md — new "When isolation does not apply" section clarifying that inline fragments are not subject to the component-isolation error.
• CHANGELOG.md — one line under ## Unreleased.

Why

Resolves the confusion raised in #76: fragments can be used purely for reuse, Apollo-style, without forcing a parent–child component hierarchy. The constant-bound style remains for when you do want ImplicitlyFetchedFieldError to guard cross-module access — the two are complementary, and the docs spell out the distinction.

Addresses #76. (Deliberately not "Closes" — see below.)

Scope / notes for reviewers

• No lib/ changes. Behaviour is unchanged; this only documents it.
• Characterization tests pinning this exact behaviour are in a companion test-only PR (test: characterize Client#parse handling of inline named fragments #81) — useful
  to review alongside, as they demonstrate the documented guarantees.
• Not closing Would it be possible to use Fragments just for pure re-usability? (without forced parent-child component encapsulation) #76 yet: the documented path currently relies on the unanchored /fragment\s*#{const_name}/
  heuristic in Client#parse, which can misfire on prefix collisions (e.g. ...UserFields vs fragment UserFieldsExtended). A follow-up will anchor that match; Would it be possible to use Fragments just for pure re-usability? (without forced parent-child component encapsulation) #76 stays open as the tracking issue until then.
• Depends on docs: add CHANGELOG and CONTRIBUTING #79 (adds CHANGELOG.md). Until that merges, this PR's diff also shows the CHANGELOG/CONTRIBUTING commit; it'll narrow to just the docs once docs: add CHANGELOG and CONTRIBUTING #79 lands.