Remove em-dashes from served discovery copy (2.9.3)

[vvillait88]

Summary

Every string these builders render onto a merchant's llms.txt, skill.md, OpenAPI document and 402 body carried em-dashes, which the house style bars on external surfaces. Because the identity and payment blocks are shared, one fix here clears the residue on every storefront at once: rendering a real store against this build now emits zero, where it was four to seven fragments per store before.

Twenty-one served strings across the discovery and challenge builders. Two worth calling out:

• The empty compatible-clients table cell rendered a bare em-dash as its placeholder. It now reads none, which is clearer than a dash anyway, and matches the Python SDK that renders the same table.
• Three doc comments said "agent-commerce". The house category term is "agentic commerce".

Comments and JSDoc are deliberately untouched. This repo has roughly 850 em-dashes, almost all in comments that carry load-bearing rationale; rewriting them would touch nearly every file, destroy blame, and change nothing a consumer reads.

Type of change

• Bug fix (no breaking change)
• New feature (no breaking change)
• Breaking change (existing callers must update)
• Docs, tests, or internal maintenance only

Public API

No signature, shape, or export changes. The rendered TEXT of discovery surfaces changes, which is the point. A consumer asserting on the exact old wording of a shared identity or payment line would need to update; nothing else is affected. Version bumped 2.9.2 to 2.9.3, patch, since client impact is text only.

Test plan

bun run lint, bun run typecheck, bun run test: 1817 passing, 4 skipped.

The meaningful check is downstream, not in this repo: I built the package and swapped the build into a real merchant's node_modules, rendered all six of its discovery surfaces, and confirmed the rendered output contains zero em or en dashes. Before the change the same render carried them. Restored the vendored copy afterwards and re-ran that store's suite to confirm it was left clean.

One string was nearly missed and is worth recording: my first sweep filtered for lines containing a quote character, which silently skipped lines inside multi-line template literals. The identity header line lived there. The rendered-output check is what caught it, which is the argument for verifying the artifact rather than the source.

Checklist

• Tests cover the new behavior, and the suite passes locally
• Lint, format, and type checks pass
• Docs and README examples updated if the public surface changed — not applicable, the public surface is unchanged
• No secrets, credentials, or personal data in the diff or the tests