[#39 follow-up] Validate the X Article GraphQL shapes against a real captured payload

[VGonPa]

The primary #39 follow-up. Gate production reliance on this.

The X long-form Article capture shipped in #39 (on develop via #65) is pinned entirely against constructed fixtures — no live X payload has ever been validated. Until that happens the structured path is unproven; it degrades safely to text-only, but we don't actually know it fires on a real Article.

Do

1. Capture one live bookmarked-Article GraphQL response (log the intercepted response(s) during a real xbrain fetch-x run against a bookmarked /i/article/…).
2. Validate the entity path (PR2): confirm article.article_results.result.rest_id resolves on the real payload.
3. Validate the content_state op-name + Draft.js shape (PR3): confirm the intercepted GraphQL op-name substring (_ARTICLE_GRAPHQL_HINT = "article") matches, and that content_state parses to ordered blocks (text runs + inline-image atomic blocks resolving via the entityMap).
4. Commit it as a recorded fixture (replace/augment the constructed fixtures in tests/test_article.py / tests/test_fetch_x.py) so drift is caught by the suite.
5. Fold in the deferred card/unified_card variant — the inline-media entity variant we deliberately skipped in Capture X long-form Articles as blogposts (body text + inline multimedia) #39.

Why it matters

The parser anchors on stable key names and degrades to (None, []) / text-only on any drift (so it's safe), but "safe fallback" is not "works". A real payload is the only thing that proves the structured blogpost path actually triggers, and it's the prerequisite for relying on this in production.

Refs: #39 (RFC open-Q #4), #65.