Playground code runner UX is confusing

The TypeScript Playground is confusing when trying to run code. It would be great to update the handbook and better yet to update the interface to make the expected behavior more clear.

1. If Settings -> "Run JavaScript in Browser" is disabled, the "Run" button is still enabled. Clicking it creates an error in the native browser console "can't access property "id", plugin is undefined". It's unclear what the "Run JavaScript in Browser" checkbox supposed to do (is there a way for the browser interface to run javascript out of browser? I think maybe it's from a previous version of the playground where JavaScript would auto-run instead of having a run button?)

2. Running code seems to fail if TSConfig Module is not "CommonJS", "None", or "Preserve".
   It fails silently if Module is "AMD" or "UMD". There is a helpful error if you have top-level exports ("[WRN]: "Tip: Change the Module setting to "CommonJS" in TS Config settings to allow top-level exports to work in the Playground"). I expect to see a warning or error if the settings are incompatible with the runner, and it's not clear which settings are compatible with the runner (e.g. I expect ES modules to work but not CommonJS in the browser, but the opposite appears true)

3. Attempting to import a package from npm often shows type hints. But running the code results in a misleading error, which is contextually inappropriate. (there is no "dependency list" that I know of to check and the import declarations are at the top of the user code in the code displayed under the .js tab).

[ERR]: "Executed JavaScript Failed:"
[ERR]: Check dependency list! Synchronous require cannot resolve module 'jest'. This is the first mention of this module!

Or:

[ERR]: "Executed JavaScript Failed:"
[ERR]: import declarations may only appear at top level of a module

Start with the linked TypeScript Playground handbook and reproduce the Run-button, TSConfig Module, and npm import cases described in the issue. Inspect the Playground settings, runner, and .js output behavior before deciding whether each case needs clearer UI feedback, documentation, or both. Done means incompatible settings and dependency errors are explained in context and the handbook describes expected runner behavior.