Claude cannot read back artifacts it published — even the owner's own artifacts in the same session

## Summary
Claude Code publishes artifacts to claude.ai (great!), but the agent **cannot read them back** — not even artifacts owned by the very account/org the session is authenticated to. This breaks a natural workflow: users turn artifacts into living documents (in our case, an operations guide for a support team), share the link back to Claude as the source of truth, and Claude can't open it.

## What happens
1. `WebFetch` on `https://claude.ai/code/artifact/{uuid}` returns:
`artifact read failed: this artifact is served to you as a public (non-member) reader, and reading public artifacts that way is not enabled yet`
This happens even though the artifact belongs to the same user/org as the session (published from a sibling session of the same account).
2. Fetching the artifact's frame URL (`*.frame.claudeusercontent.com/...`) returns the same error.
3. Workaround attempts via the Chrome extension also fail: the artifact renders inside a sandboxed cross-origin iframe, so `get_page_text`/`read_page` see an empty shell, synthetic scroll/click events don't reliably drive the inner document, and the parent's `/api/frame/{uuid}` endpoint returns 404 when replayed without the app's internal headers.

## Why it matters
The artifact tooling itself encourages using artifacts as shareable, updatable deliverables. If the agent that created them can't re-read them, round-tripping (user edits/iterates in another session → asks this session to reconcile against 'the latest version') requires the user to manually copy content back into chat. My user's summary: *'demasiado menso desarrollar artefactos y que estos no sean legibles por ustedes mismos'* — hard to argue with that.

## Expected
`WebFetch` (or a dedicated Artifact read action) should return the content of an artifact the session's account owns — the same trust boundary that already allows *updating* an owned artifact via the Artifact tool's `url` parameter.

## Environment
- Claude Code (desktop app, macOS), model claude-fable-5
- Session authenticated to the same claude.ai org that owns the artifact

*Filed by Claude at the user's request from an interactive session.*

Start by reproducing the failure with WebFetch against an owned artifact URL and its frame URL, then compare the result with the documented update path using the Artifact tool's url parameter. Done means a session authenticated to the owning account can read the artifact content, including after it has been edited in another session.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.