docs: name target in the list_artifacts description (T2.1.7 follow-up)

[kuyazee]

What this was

The follow-up T2.1.7 left behind, listed under its own item in backlog 2: "The MCP list_artifacts
description still enumerates the response without target." PR #37 rewrote that same string, so
editing it then would have conflicted. #37 merged (6c1911a), so the line is unowned now.

What changed

GET /api/artifacts has returned target for a redirect since PR #40, and list_artifacts hands
back the same publicMeta output, so an agent has been receiving the field for a day without being
told. Three lines of the repo said otherwise:

• The tool description lists the response fields by hand. target joined the list, plus one
  sentence saying what it is and that a redirect published before targets were stored on the
  artifact has none.
• docs/mcp.md said only "JSON list" in the tool table. It now names every field the tool returns,
  in the same order, with the same caveat.
• The smoke suite publishes a redirect over REST before the existing list_artifacts call, then
  checks two things on the one response: the entry carries target with the URL that was published,
  and the served description names target.

No route, no handler, no storage change. The behavior was already right; the strings describing it
were not.

Tests

npm test 49, unchanged. bash .github/workflows/smoke.sh 154 ok: lines, with the two new
assertions folded into the list_artifacts line rather than a new one.

Both new assertions were checked against something that fails:

• The description half went red on this checkout before the string changed. The FAIL line printed
  the whole served description, which is how the missing field is read off a CI log.
• Dropping target from PUBLIC_META_FIELDS takes the field out of every list response. That run
  goes red, though the REST assertion from feat: compose, show and repoint a redirect from the dashboard (T2.1.7, T2.1.10 to T2.1.12) #40 ("redirect row is missing its target") trips first,
  40 lines earlier, so the MCP half is the second line to fail rather than the first.
• The pattern is target[^,]*<url> on one line, because the whole pretty-printed list arrives
  escaped on a single SSE line. Checked that it matches "target": "<url>", misses the same URL
  under a renamed field, and misses a target holding a different value.

The slug is ci-redir-mcp, not ci-mcp-redirect: two assertions in that block grep the list for the
bare string ci-mcp, and a slug carrying it as a prefix would satisfy them after ci-mcp itself
stopped being published. The block already carries that warning for ci-mcp-default.

No screenshot. Nothing in the dashboard changed; the visible surface is a string an MCP client reads.

Review

26 changed lines, so the four lenses were run here rather than by subagents, per the runner's own
table. Nothing reachable without a key changed, and lib/auth.js and the serve paths were not
touched.

• Adversarial: a leftover ci-redir-mcp from an aborted run would 409 the publish, so the
  cleanup block at the top of the MCP section deletes it first, the way it already does for
  ci-mcp, ci-mcp-denied and ci-vis-default. The publish uses curl -sf and fails loudly
  rather than letting a later grep report the wrong cause.
• Security: the redirect is public and points at example.com, and the suite deletes it in the
  same block. No key, cookie or token enters the new lines.
• QA: covered above. The response half overlaps the REST assertion from feat: compose, show and repoint a redirect from the dashboard (T2.1.7, T2.1.10 to T2.1.12) #40 on purpose; what it
  adds is that the MCP transport carries the field, which nothing checked.
• UX: the description is what an agent reads. It names the field in the existing sentence rather
  than appending a new clause at the end, and says plainly when the field is absent.

Nothing was filed. Nothing was fixed outside the item.