test: Remove old auto instrumentation e2e tests

[Stephen Belanger (Qard)]

Summary

• The end-to-end auto-instrumentation tests were generating fixture scripts at runtime via fs.writeFileSync, then cleaning up with fs.unlinkSync
• When tests failed, the cleanup never ran, leaving stale untracked .mjs files in the fixtures directory
• Moves each fixture to a static file committed alongside the test, removes the dynamic generate/cleanup logic from the test

Test plan

• cd js && pnpm test — end-to-end tests reference static fixture files directly
• No more untracked files after a test failure

🤖 Generated with Claude Code

[Luca Forstner (lforst)]

Do you think instead of having these tests at all we could move them to the "new" E2E tests?

In general these tests seem to operate on a weird assertion level - like call api from user perspective but assert on an internal. I don't particularly like that.

[Stephen Belanger (Qard)]

I've removed those. They were also validating a channel name mismatch though, which are implementation details, but also represents a real bug which probably should be covered. Should we check that internal value in the true e2e tests, or do you feel the e2e test passing is sufficient evidence of that being correct?

I generally prefer more unit tests as they can catch a lot of cases where a thing works by accident and you don't realize until much later that it's been subtly broken and just not in a way that e2e tests reflected.

[Luca Forstner (lforst)]

Should we check that internal value in the true e2e tests, or do you feel the e2e test passing is sufficient evidence of that being correct?

In this particular case, I think the e2e tests are enough because with the current architecture, if the channels don't match the e2e tests will scream at you very loudly.

I generally prefer more unit tests as they can catch a lot of cases where a thing works by accident and you don't realize until much later that it's been subtly broken and just not in a way that e2e tests reflected.

I personally like to have both. For things that are side-effect free and have a limited scope, I like unit tests. For everything that may be influenced by external factors and/or is more complicated and/or has side-effects, I usually prefer integration/e2e tests. I always gravitate towards the latter more because the coverage you get is much broader usually and also more reflects how users are seeing our product, which is arguably the most important thing.