feat(dvm): add dvm worker registry settings and process topology

[Priyanshubhartistm]

Description

Adds the worker registry and process topology needed before the relay can route NIP-90 DVM jobs to external worker processes. This is a foundation/skeleton PR - no job ingestion or IPC dispatch yet.

• Adds a dvm: settings section (Dvm / DvmWorker types in src/@types/settings.ts, default dvm: workers: [] in resources/default-settings.yaml) so operators can register DVM workers (command, args, accepted job kinds, timeout), following the exact same shape as the existing mirroring.static list-of-configs convention.
• Wires a new WORKER_TYPE=dvm-orchestrator process type into the cluster topology: App.run() forks one process per configured dvm.workers[] entry (mirroring the existing mirroring.static fork loop), and src/index.ts's getRunner() dispatches to a new factory.
• Adds a skeleton DvmOrchestratorWorker (src/app/dvm-orchestrator-worker.ts) implementing the repo's IRunnable interface: reads its assigned config via DVM_WORKER_INDEX, wires standard
  SIGINT/SIGHUP/SIGTERM/uncaughtException/unhandledRejection handling matching
  MaintenanceWorker/StaticMirroringWorker, and exits non-zero if no config is found for its index. It does not spawn or dispatch jobs yet.
• Documents the new dvm.workers[] settings in CONFIGURATION.md.

Related Issue

Part of #639

Motivation and Context

Nostream has no support for Data Vending Machines (NIP-90) today. The DVM kind range (5000-6999) is used in production by real services despite the NIP's unrecommended status upstream, so the relay needs to handle these events properly. Before job routing, lifecycle tracking, or IPC dispatch can be built, the relay needs a place for operators to register available DVM workers and a process topology to run them in — that's what this PR adds. Job ingestion (trapping kind 5000-5999 events) and IPC dispatch (spawning workers, sending jobs, publishing results) are separate, independently reviewable follow-up PRs.

How Has This Been Tested?

• Added unit tests for DvmOrchestratorWorker (startup with a valid config, exit(1) when no config exists for the assigned index, signal handling on SIGTERM, close() callback invocation) and for dvmOrchestratorWorkerFactory 5 new tests total, following the existing MaintenanceWorker/maintenanceWorkerFactory test conventions (Sinon-stubbed process EventEmitter, stubbed settings function).
• Ran the full local CI suite:
  • pnpm exec commitlint --from=upstream/main --to=HEAD
  • pnpm exec changeset status --since upstream/main
  • pnpm lint, pnpm check:format (touched files), pnpm check:deps
  • pnpm run build:check, pnpm run build, pnpm run verify:cli:build
  • pnpm run test:unit — 1505 passing
  • pnpm run test:cli — 73 passing
  • pnpm run cover:unit — new files at 91.66%/100% coverage
  • pnpm run docker:test:integration — 99 scenarios / 489 steps passing (ran this despite the
    change being additive, since it touches the primary process's fork loop in app.ts and the
    WORKER_TYPE dispatch in index.ts)
• Manually verified dvm.workers defaults to [], so no dvm-orchestrator workers are forked and existing topology (client workers, maintenance worker, static-mirroring workers) is unaffected unless an operator explicitly configures dvm.workers.

Screenshots (if appropriate):

N/A — process topology / settings change, no UI.

Types of changes

• Non-functional change (docs, style, minor refactor)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my code changes.
• I added a changeset, or this is docs-only and I added an empty changeset.
• All new and existing tests passed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 8257e7f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
nostream	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR