feat: add native DSH threat-feed subscriptions and notifications

[Mr-Lucky]

Summary

Add native DSH threat-feed subscription management with persistent state and dedicated DSH tools.

Deliver durable, deduplicated threat-feed notifications to active DSH sessions through a secure local queue.

Extend self-check discovery to cover DSH artifacts, harden cleanup and cron error handling, and document the complete subscription workflow.

Type

• Bug fix
• New feature / detection rule
• Refactoring
• Documentation

Testing

• npm run build passes
• npm test passes (595 tests)
• Manually tested the change

Related Issues

Closes #

[github-actions]

AgentGuard PR Review

I found a concrete regression and a security issue in the new DSH subscribe flow.

1. severity: high — src/dsh/plugin.ts (subscribe tool execute)

   • What can go wrong: the tool calls subscribeCloudFeed(config) and installCron(...) before persisting the new subscription state. If persistence fails, the catch block only rolls back when subscriptionSaved is true, but that flag is set only after saveSubscription(...) succeeds. In the common failure path where cron is already installed and state write fails, the code will remove the cron only if cronResult.created is true, but it never restores the prior config or guarantees the old subscription remains intact if saveSubscription(existing, home) fails during forced replacement. This can leave a working cron pointing at a missing or mismatched local state, causing silent breakage or orphaned polling.
   • Concrete fix: persist the new subscription state first (to a temp file / staged state), then install the cron, then commit the config; or add a robust transaction wrapper that records every prior artifact and rolls back all mutated state on any failure, including restoring the previous subscription and config unconditionally on rollback failures.

2. severity: medium — src/dsh/plugin.ts / src/feed/dsh-subscription.ts

   • What can go wrong: the subscribe tool accepts only exec?.agent?.id but there is no validation that this id is actually an authenticated DSH session identity from the runtime context. A forged or injected execution context could bind the subscription to an attacker-chosen agent id, leading to notification delivery to the wrong session and possible cross-session data exposure.
   • Concrete fix: require the DSH runtime to supply a signed/verified session identity object (not just a free-form string), and validate it against the active agent/session registry before creating or replacing the subscription.