basalt status reports `modified` right after a successful publish for docs with local images

[A-PachecoT]

Carried forward from #5 problem (2), so it is not silently closed when #5's problem (1) (the dirty-list) is fixed by #11.

The bug

basalt status reports modified for a doc that was just published successfully, with no edit in between, whenever the doc references local images.

basalt publish ship-log/x.md   # → modified ... [assets: 0↑ 4✓]
basalt status  ship-log/x.md   # → modified     ← nothing was edited

Why

Publish rewrites local image refs (./assets/x.png → /files/<vault>/_assets/<hash>-x.png) and normalizes frontmatter, without touching the local .md — this is documented in --help. So the canonical source can never match the local file byte-for-byte, and the comparison is being made against the wrong side of a transformation the publish itself performed.

Why it matters beyond the wrong word

status is the only command that answers "is this published?". For a vault of ship-logs — where nearly every doc carries images — it cannot answer it for any of them.

Concretely, this already changed a design decision: #11 needed a publish-state oracle for the Stop hook, and basalt status was the obvious choice (it was proposed in #5's own comment thread). It was rejected partly on this: building on it would have made the hook fail precisely in the vault shape where the bug was reported, and fail silently. #11 derives publish-state from local git and harness state instead.

Proposed fix

Compare against the post-transformation sha — apply the same rewrite to the local content before hashing — or exclude the refs that publish rewrites from the hash.

Acceptance

• basalt status <f> on a freshly published doc with local images, unedited → unchanged
• edit only that doc's body → modified

Scope

The status/publish comparator, i.e. the CLI — not the plugin's hook surface.

[A-PachecoT]

The fix is smaller than this issue proposes — and it is not in this repo

Measured today before taking this, against the installed basalt-cli@0.10.0 and the CLI source.

1. The post-transformation comparison already exists. publish has it; status does not.

This issue proposes "compare against the post-transformation sha — apply the same rewrite to the
local content before hashing". That is already implemented, on one of the two code paths:

cli/src/commands/publish.ts:143   withRewrittenBody(local, body)
                                  → recomputes sha + shaCandidates over the REWRITTEN body
cli/src/commands/publish.ts:189   "Content-addressed skip (against the REWRITTEN body's sha)"

cli/src/commands/status.ts:25-31  loadLocalDoc(file) → classify(local, server)
                                  → no resolveAssets, no withRewrittenBody: hashes the RAW body

cli/src/local-docs.ts:186 hashes body verbatim, and cli/src/remote.ts:79 compares that against
the server's current_sha. The server stores the sha of the source it receives, which is the
rewritten one. So publish compares like against like and correctly reports skipped, while
status compares the raw body against a rewritten sha and can only ever say modified.

So there is no transformation to design. The rewrite exists, is already proven to be a pure function
of the image bytes (publish.ts:12-14 states exactly this, which is what makes the post-rewrite body
stable across runs), and status simply does not call it. withRewrittenBody is currently private to
publish.ts — the change is to lift it (to remote.ts, next to classify) and use it from status.ts.

2. Both acceptance arms fall out of that, including the one that usually gets skipped

• freshly published doc with local images, unedited → unchanged: the rewritten sha is what the
  server stored, so it matches.
• edit only that doc's body → modified: the rewrite is pure over the image bytes, so a body
  edit changes the rewritten body too. The sensor is not switched off — which is the failure mode
  to check for, since a fix that makes status never say modified has deleted the command rather
  than repaired it.

The mutation that proves the pair: make the rewrite a no-op and arm 1 must go red; make status
always report unchanged and arm 2 must go red.

3. Routing — this cannot be fixed in cofoundy/basalt-plugin

The scope line on this issue is right ("the CLI — not the plugin's hook surface"), and the
consequence is that the fix surface is not in this repo at all. basalt is the basalt-cli npm
package, whose package.json declares repository: github.com/cofoundy/basalt, directory: cli — the
private repo, per ADR 0001. This repo contains only commands/, hooks/, skills/ and .mcp.json;
there is no CLI source here to change.

Two related notes for whoever picks it up:

• The plugin never calls basalt status in any hook — verified by grep, with a positive control
  on the same probe (basalt publish returns hits). fix(hooks): make the dirty list mean "edited since last publish" (#4 + #5) #11's decision to derive publish-state from local
  git and harness state instead of status means this bug does not reach the hook surface.
• It does reach the plugin's doctrine: commands/basalt.md:33 and
  skills/basalt/references/cli-path.md:43 both tell the agent to run basalt status <file> --json
  to confirm the vault binding before a first publish. That specific use reads the project field,
  not the status word, so it still works — but the plugin is pointing users at a command that
  misreports for any doc with local images.

Recommend moving this issue to cofoundy/basalt with the diagnosis above.