chore: remove axios dependency, use native fetch, add CI

[phainv]

Summary

• Replace axios with native fetch in test steps — axios was only used for a single GET request in cucumber tests
• Remove axios from devDependencies and example/ dependencies
• Remove tracked example/package-lock.json (already covered by .gitignore)
• Add GitHub Actions workflow to run tests on Node 18, 20, and 22

Motivation

axios is an unnecessary dependency here. Node 18+ provides global fetch natively, which handles the simple GET request in the test suite. This reduces the dependency footprint for contributors.

Test plan

• All 26 cucumber scenarios pass locally (199 steps)
• CI runs green on Node 18, 20, 22

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f671f9f193

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[vovito]

Nice cleanup — axios was clearly overkill for a single test-suite GET.

One small suggestion before merging: since native fetch is only available globally on Node 18+, it's worth declaring that requirement in package.json so installs on older runtimes get a warning instead of failing at test time with ReferenceError: fetch is not defined:

"engines": {
  "node": ">=18"
}

I've prepared the change on claude/review-pr-33-hJEvQ (f26fe9a) if it's easier to cherry-pick than to redo. Happy to open it as a follow-up PR after this merges instead — whichever you prefer.

One other minor thought (non-blocking): axios.get() rejects on non-2xx, but fetch() only rejects on network errors. If the widget URL ever returns 4xx/5xx, the test will read the error body as htmlBody and the assertion will fail with a confusing "expected text not found" rather than a clear HTTP error. A if (!response.ok) throw new Error(...) guard would preserve the original behavior, but low risk in practice.

---

Generated by Claude Code