fix(responses): reject ambiguous timestamp prefixes in show

[dchaudhari7177]

Closes #13.

survey responses <id> show <prefix> returned the first match when the prefix matched more than one timestamp — exit 0, no warning, potentially the wrong response. delete already rejected this.

What changed

readResponse now mirrors deleteResponse: collect every matching entry, return null for none, throw AmbiguousResponsePrefixError for more than one. In cli.ts the show branch moves inside the try/catch that already renders that error for delete, so both commands report ambiguity identically.

One thing beyond the literal ask, which I think is the right call but is worth a look: resolution also moves from listResponses (which matched on the timestamp field inside the JSON) to the enumerated filename — the rule deleteResponse already documents as "the enumerated filename is the authoritative response identity". Left as-is, a response whose metadata timestamp disagreed with its filename would make show <prefix> and delete <prefix> resolve to different responses. There's a test pinning that. Say the word if you'd rather keep the change strictly to the ambiguity check.

Acceptance

• ✅ show still accepts an exact timestamp and a unique prefix
• ✅ ambiguous prefix exits non-zero and prints all matching timestamps
• ✅ no response files modified — the test asserts file contents are byte-identical after the rejection
• ✅ storage and CLI tests cover unique, missing, and ambiguous prefixes (6 new tests)

Verification

bun run typecheck clean.

bun test on this branch: 46 pass, 3 fail. Baseline on main: 40 pass, 3 fail — same three failures, so the 6 new tests pass and nothing regressed.

Both numbers are with NO_COLOR=1. Without it I get 5 failures on main, and the two extra are an environment artifact worth knowing about: picocolors detects colour support on this terminal, so documented responses show/delete syntax fail comparing "Deleted …" against "\x1b[2mDeleted …\x1b[22m". Not related to this change — they fail identically on pristine main.

The 3 remaining failures (discoverSurveyFiles, two standalone scaffold) are also pre-existing; discoverSurveyFiles is a Windows path-separator issue, returning absolute paths where the test expects bare filenames.

[vercel]

@dchaudhari7177 is attempting to deploy a commit to the Crafter Station Team on Vercel.

A member of the Team first needs to authorize it.