fix(deliverables): keep scoped packages and emails out of file links

[lswang9]

Fixes #85

Problem

localPathReference renders inline code as a clickable produced-file chip. Its fallback accepted two shapes far too eagerly:

• anything containing / → a scoped package name like @deepseek-ai/cordis looked like a path
• anything matching name.suffix → an email address like user@example.com looked like a filename

So assistant prose mentioning a package or an email rendered a file chip that opens a path which never existed. Verified against the pristine vendored 0.1.2-rc.1 bundle with only the current main patch applied:

LINK   "@deepseek-ai/cordis"       -> "@deepseek-ai/cordis"
LINK   "@foo/bar"                  -> "@foo/bar"
LINK   "@plugin/name"              -> "@plugin/name"
LINK   "user@example.com"          -> "user@example.com"
LINK   "first.last@sub.example.co" -> "first.last@sub.example.co"

Change

Two rejection rules in patches/@deepseek-ai+dsh-client-ui-deliverables+0.1.2-rc.1.patch, placed after the absolute/relative prefix check so explicit paths keep winning:

if (/^@[^\\/@\s]+\/[^\\/@\s]+$/.test(path)) return void 0;              // @scope/name
if (/^[^@\s\\/]+@[^@\s\\/]+\.[A-Za-z]{2,}$/.test(path)) return void 0;  // local@domain.tld

Only a bare @scope/name with a single slash, or a bare local@domain.tld, goes inert. Paths that merely contain an @ segment are unaffected — ./@scope/pkg, /tmp/@scope/pkg/index.js and node_modules/@foo/bar/lib/client.js still resolve, because the prefix check or the multi-segment slash rule matches first.

Nothing else moves: produced-file resolution, basename matching, #L42 / :42:7 suffix stripping, and the paths ?? [] fallback are untouched.

Verification

Ran against the real target, not the installed tree — my node_modules held 0.1.1-rc.1, so I extracted the vendored packages/harness-0.1.2-rc.1/npm-dsh/deepseek-ai-dsh-client-ui-deliverables-0.1.2-rc.1.tgz and worked from that.

• patch-package applies to pristine 0.1.2-rc.1: @deepseek-ai/dsh-client-ui-deliverables@0.1.2-rc.1 ✔
• Behaviour on the patched real bundle: all 7 inert cases inert, all 7 path cases resolve unchanged
• Bug reproduced first on main's patch against the same pristine bundle (5 false links above), confirming this is not an artifact of my setup
• npx vitest run test/local-path-links.test.ts → 6/6 pass
• Reverting only the patch and rerunning fails exactly one test (the scoped-package/email case) and passes the other five, so the new test pins this regression specifically
• Full suite unchanged vs. main baseline: 29 failed / 656 passed before, 29 failed / 661 passed after — same 12 failing files, the 5 extra passes are the new cases. Pre-existing failures come from stale local deps, not this change
• npm run typecheck: 10 errors before and after, none in the touched files

Test

test/local-path-links.test.ts keeps the 5 original text assertions and adds behavioural coverage. It evaluates the helper extracted from the patch text rather than from node_modules, so it stays honest when the installed Harness build and the patch target disagree.

Note for reviewers

One judgement call: Array.prototype.map and v0.7.1 also come back as links from the same name.suffix rule. I left them alone — tightening that needs either an extension allowlist or a stricter last-segment test, and both risk dropping legitimate uncommon file types. Happy to follow up separately if you want it narrowed.