Cleanup shared configs

[Pearce-Ropion]

Summary

Reverses direction from the original "move __VERSION__ into root base configs" — instead, all @sigmacomputing/plugin-specific settings are pulled out of the shared root configs and pushed into packages/plugin-sdk/. The root base configs now hold only settings that genuinely apply to every workspace package.

Moved out of root base configs into packages/plugin-sdk/:

• tsdown.base.ts → packages/plugin-sdk/tsdown.config.ts: __VERSION__ define, inputOptions.transform.jsx: 'react', and the UMD outputOptions (entryFileNames, globals.react, name).
• vitest.base.ts → packages/plugin-sdk/vitest.config.ts: __VERSION__ define, oxc.jsx, and the react/jsx-dev-runtime optimizeDeps entry.
• tsconfig.app.json → packages/plugin-sdk/tsconfig.app.json: "jsx": "react".

Other tightening in the root bases:

• vitest.base.ts test include narrowed from src/**/*.test.{js,jsx,ts,tsx} to src/**/*.test.{ts,tsx} (no JS/JSX test files in workspace packages).

Test plan

• yarn turbo build succeeds and the UMD/ESM/CJS bundles still embed the correct version at __VERSION__ (consumed in packages/plugin-sdk/src/client/initialize.ts:54) and produce sigmacomputing-plugin.umd.js with the SigmaPlugin global.
• yarn turbo test passes — __VERSION__, JSX transform, and react/jsx-dev-runtime resolution still work from the package-local vitest config.
• yarn turbo types / tsc -b passes — jsx: "react" is correctly picked up from the package's tsconfig.app.json.

[rilescode]

Would this be an issue if someone manually updates the version in plugin-sdk/package.json without using yarn bump? They could get out of sync

[peternandersson]

I'd rather have this just in the plugin-sdk package since it's the only one that needs the value injected

[Pearce-Ropion]

I'd rather have this just in the plugin-sdk package since it's the only one that needs the value injected

This is prep work for splitting the package into multiple sub-packages. Should each one inject its own version thus requiring duplicated code for each package's tsdown config?

Would this be an issue if someone manually updates the version in plugin-sdk/package.json without using yarn bump? They could get out of sync

This would generally be a problem and that code should not be landed. The whole package should remain in sync.

[Pearce-Ropion]

I'd rather have this just in the plugin-sdk package since it's the only one that needs the value injected

Thought about this more and in hindsight, you are totally right. I am going to change this PR to be more focused on cleaning up duplicate configuration in the tsdown config.