fix(observability): avoid mutating captured error names

[JSONbored]

Motivation

• Capturing errors with an optional eventName previously mutated the original Error instance's name, which throws for Error-like objects with read-only name (e.g. DOMException from AbortSignal.timeout) and can crash observability/error handlers.
• The change prevents the observability path from becoming a secondary failure during error reporting and preserves triage information.

Description

• Replace in-place renaming with a synthetic Error when eventName is provided, setting the original error as the synthetic error's cause and copying the original stack to preserve triage context.
• Implement namedCaptureError to return the original Error unmodified when no eventName is given, and to construct a new Error(err.message, { cause: err }) with name set to eventName when provided.
• Use Object.defineProperty to assign the stack on the synthetic error to avoid writable/descriptor issues.
• Add regression unit tests that exercise captureError and captureReviewFailure with a DOMException timeout and a frozen Error to ensure the original objects are not mutated and the synthetic error preserves message, stack, and cause.

Testing

• Ran the updated unit suite file with npx vitest run test/unit/selfhost-sentry.test.ts and the tests passed.
• Ran coverage for the targeted test with npm run test:coverage -- test/unit/selfhost-sentry.test.ts and the targeted tests passed, though global coverage thresholds fail when only a single test file is executed in isolation.
• Ran typechecking with npm run typecheck and it failed due to unrelated, pre-existing TypeScript issues elsewhere in the repository that are outside the scope of this change.

---

Codex Task

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[gittensory-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-12 21:50:51 UTC}

2 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This fix replaces in-place mutation of a captured error's `name` with construction of a synthetic `Error` (via `Error(message, {cause})` plus a defined `stack` property), avoiding a crash when the original error has a read-only `name` descriptor (e.g. DOMException from AbortSignal.timeout). The logic is correct: when no eventName is given the original error is returned unmodified, and when given, a new Error is built without touching the original. Tests directly exercise the DOMException and frozen-Error cases and assert both the original object is untouched and the synthetic error preserves message/stack/cause, which is exactly the right regression coverage.

Blockers

• PR fix(observability): avoid mutating captured error names #5432 description links only a Codex task and no eligible open JSONbored/gittensory issue, so per repository policy I can't mark this merge-ready until you add the maintainer-authorized issue link or explain why this is exempt.

Nits — 5 non-blocking

• src/selfhost/sentry.ts: `Object.defineProperty` for `stack` sets `writable: true` but omits `enumerable`, so it defaults to false — likely fine but worth a one-line comment noting this is intentional to match native Error.stack semantics.
• The updated docstring is good but could explicitly state that the returned Error is a *new* object when eventName is set, to make the no-mutation contract obvious to future readers skimming just the comment.
• Consider extracting the synthetic-error construction into a small named helper if it's ever needed elsewhere, though at a single call site the inline version is fine as-is.
• src/selfhost/sentry.ts:439 defines the synthetic stack, but test/unit/selfhost-sentry.test.ts:621 does not assert stack preservation even though the PR explicitly claims that behavior.
• Add an assertion in test/unit/selfhost-sentry.test.ts:621 that `lastCapturedError().stack` equals the original error stack for the eventName path.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue — Link the relevant issue (for example `Closes #123`) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 44 registered-repo PR(s), 36 merged, 435 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 44 PR(s), 435 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Ruby, Go, JavaScript, MDX, Shell, Solidity
• Official Gittensor activity: 44 PR(s), 435 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.37%. Comparing base (dc94169) to head (e211114).
⚠️ Report is 62 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5432      +/-   ##
==========================================
- Coverage   94.41%   94.37%   -0.04%     
==========================================
  Files         550      550              
  Lines       44143    44146       +3     
  Branches    14632    14632              
==========================================
- Hits        41677    41663      -14     
- Misses       1791     1808      +17     
  Partials      675      675              

Flag	Coverage Δ
shard-1	43.74% <100.00%> (-0.25%)	⬇️
shard-2	34.11% <0.00%> (-0.52%)	⬇️
shard-3	32.15% <0.00%> (+0.55%)	⬆️
shard-4	31.19% <0.00%> (-0.06%)	⬇️
shard-5	33.08% <0.00%> (-0.21%)	⬇️
shard-6	43.60% <0.00%> (+0.20%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/selfhost/sentry.ts	99.64% <100.00%> (+<0.01%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.