[BUG] Artifact publish: "identical content already refused ... resent unchanged" for content whose hash changed

## Summary

Republishing an existing artifact from a local file is refused by two different gates, and the second one's message is factually wrong: it reports **"identical content already refused ... resent unchanged"** for content that demonstrably differs from both the live version and the previous submission.

Version: `2.1.233` (Claude Code), macOS arm64.

## What I observed

Two refusals come from two different components. Grepping the running binary for each half of the two messages:

| String | Present in the `2.1.233` binary? |
| --- | --- |
| `viewed the live version`, `counts as viewed`, `baseVersion` | yes |
| `identical content`, `resent unchanged`, `already refused`, `nothing was merged or published`, `use force:true only` | **no** |

So the "hadn't viewed the live version" gate is client-side, and the "resent unchanged" gate is server-side.

## Reproduction

1. Publish a local `.html` to an artifact. Later, from a new session, edit the file so it is a strict superset of the live version.
2. `Artifact` with `url` → refused: *"You hadn't viewed the live version of this artifact"*. The full source is saved to a local file.
3. `Artifact action:"read"` on the same URL, then `Read` **every line** of that saved file.
4. Publish again → refused: *"this is the identical content already refused against the newer version ..., resent unchanged."*
5. Materially change the file (I bumped a version field and added a changelog entry; `md5` changed from the previous submission).
6. Publish → refused again with **"hadn't viewed the live version"**, which appears to burn the new content against the server-side gate.
7. `read` again, publish the changed content → refused with **"identical content ... resent unchanged"**, although the content is not identical to anything previously accepted and differs from the live version.

## Expected vs actual

- **Expected:** either the publish succeeds, or the refusal accurately describes why.
- **Actual:** the refusal asserts the content is identical and unchanged when its hash differs. Acting on the message as written ("merge your edits onto that version's source") cannot clear it, because the content already contains everything the live version has.

## Things I ruled out by experiment

- **Not file-path keyed** — publishing the same bytes from a different path produced the same refusal.
- **Not cleared by editing** — a real content change (new hash) did not clear it.
- **`force: true` works.** That appears to be the only escape, and it is the correct outcome here since I had read and diffed the live version. It is also undocumented.

## Why this matters

The message sends you to do a merge that is already done, and the only working escape is a flag that appears in no public documentation ([Claude Code artifacts](https://code.claude.com/docs/en/artifacts), [Compliance API](https://platform.claude.com/docs/en/api/compliance/apps/artifacts), [support article](https://support.claude.com/en/articles/9547008-publish-and-share-artifacts)). A wholesale supersede — republishing a document that is many revisions ahead — has no documented non-force path.

## Suggestions

1. Make the message say what is actually true — e.g. *"this content was already rejected in this session"* — rather than "identical content".
2. Document `force`, and document the intended flow for a legitimate supersede.
3. Consider not recording a submission as "refused" when it was rejected by the *client-side* view gate, since the server never evaluated it.

Start with the Artifact publish flow using url, action:"read", and force:true, then compare the client-side view gate with the server-side unchanged-content refusal described in the report. No source files or tests are named; done means reproducing the hash mismatch, identifying the refusal-state problem, and making the message and documented supersede flow accurate.

Written by the indexing model from the issue text.