feat: migrate build pipeline from tsc to tsdown

[chybisov]

Which Linear task is linked to this PR?

EMB-317: Migrate SDK and Widget build pipelines from tsc to tsdown

Why was it implemented this way?

Replace tsc --build with tsdown (powered by Rolldown/OXC in Rust) across all 9 library packages. Full build time drops from ~78s to ~6s (~13x faster).

Before vs After

Metric	Before (tsc)	After (tsdown)	Improvement
Full build time	~78s	~6s	~13x faster
Build passes per package	2 serial (ESM, cleanup)	1 (ESM+DTS)	Fewer passes
Type checking	Coupled with build	Separate check:types step	Build never blocks on type errors

What changed

Root:

• Added tsdown as root devDependency
• Added isolatedDeclarations: true to root tsconfig (enables OXC-powered .d.ts generation)
• Simplified root build script to run all packages in parallel

Per library package (9 packages):

• Created tsdown.config.ts with consistent config: unbundle: true, format: 'esm', outDir: 'dist/esm', target: 'es2020'
• Replaced multi-step tsc build with single tsdown command
• Widget package adds neverBundle: [/\.json$/] for i18n JSON files

App packages (widget-embedded, widget-playground-vite, nft-checkout):

• Override isolatedDeclarations: false in tsconfig (they don't emit declarations)
• Remain on Vite builds, unchanged

Source files (~370 files):

• Added explicit return type annotations to all exported functions/constants (required by isolatedDeclarations)
• Added explicit type annotations to exported createContext() and styled() results
• Converted all inline import('...').Type patterns to proper import type statements

Why tsdown?

• Rust-powered: Uses Rolldown (Rust bundler) + OXC (Rust TypeScript toolchain) instead of JavaScript-based tsc
• isolatedDeclarations: Each file's .d.ts is generated independently without cross-file type resolution
• Drop-in: Output is semantically equivalent to tsc — same file structure, same module format, same declaration files
• Proven: Already migrated the SDK repo (lifinance/sdk#369) with ~20x speedup

Checklist before requesting a review

• I have performed a self-review and testing of my code.
• This pull request is focused and addresses a single problem.
• If this PR modifies the Widget API or adds new features that require documentation, I have updated the documentation in the public-docs repository.