Deprecation warnings on root import are unfilterable (console.warn instead of process.emitWarning)

[Leestex]

Describe the issue

Importing the root specifier @hatchet-dev/typescript-sdk prints seven red console.warn lines on every process start, because:

• sdks/typescript/src/index.ts re-exports both ./workflow and ./step.
• sdks/typescript/src/workflow.ts runs four console.warn(...) calls at module evaluation.
• sdks/typescript/src/step.ts runs three console.warn(...) calls at module evaluation.

Both submodules are pulled in unconditionally even by consumers who only use v1 symbols re-exported from ./v1, because the root index re-exports them as a side-effect.

Because the messages use raw console.warn rather than process.emitWarning, they:

1. Cannot be filtered by the standard Node flags users reach for to suppress deprecation noise — --no-deprecation, --no-warnings, --no-warnings=DeprecationWarning all have no effect.
2. Cannot be deduplicated — both submodules print the same four-line banner, so the user sees two near-identical blocks per process boot. There's no per-process once-only behavior.
3. Do not carry a code, so users who genuinely want to filter (e.g. via process.on('warning', …)) have no stable identifier to match on.

The package already ships a one-shot deduplication helper at sdks/typescript/src/v1/client/worker/deprecated/deprecation.ts (emitDeprecationNotice with an alreadyLogged Set), but workflow.ts and step.ts don't use it.

Environment

• SDK: @hatchet-dev/typescript-sdk@1.22.2
• Runtime: Node.js 24.13 (native ESM, type: "module")
• Engine: Cloud — latest

Expected behavior

Either:

• The deprecation messages emit via process.emitWarning(message, { type: 'DeprecationWarning', code: 'HATCHET_V0_REMOVED' }), which Node de-dupes by code, makes filterable via standard flags, and surfaces with consistent formatting — or
• The existing emitDeprecationNotice helper is used uniformly across workflow.ts and step.ts so the messages emit at most once per process and respect a consistent deprecation surface.

The intent of nagging users to migrate is preserved either way — the warnings remain visible by default. The change is purely about giving consumers a standard, scoped way to filter and de-dupe.

Reproduce

npm i @hatchet-dev/typescript-sdk@1.22.2
node --input-type=module -e "import('@hatchet-dev/typescript-sdk').then(() => {})"
# prints seven red console.warn lines
node --no-deprecation --input-type=module -e "import('@hatchet-dev/typescript-sdk').then(() => {})"
# still prints the same seven lines — the flag has no effect

Additional context

Separate from #3613 / #3650 — those address the missing exports map so the /v1 subpath resolves in ESM. This issue is about the root-path warning emission strategy, which would persist even with /v1 available because (a) the documented examples in the v1 setup guide and Context7 still show import { Hatchet } from '@hatchet-dev/typescript-sdk', and (b) older codebases importing from root will keep doing so until they're explicitly migrated.

Happy to send a PR migrating both workflow.ts and step.ts to process.emitWarning with a HATCHET_V0_REMOVED code if that's the preferred shape — wanted to confirm direction first.