Move to a better type system

[81reap]

Currently the front-end is a bunch of JavaScript files typed with JSDoc which has limitations such as ::

1. Doesn't allow for new features to be added easily add @legacy tag jsdoc/jsdoc#2139
2. Doesn't support negative numbers JSDOC cannot parse negative numbers in type expressions. jsdoc/jsdoc#2131 and a fix has been open for a while now feature: update parser to allow negative numbers hegemonic/catharsis#76

If we switch the frontend over to Typescript, it will cost us a build step but we gain ::

1. shared types between test and prod
2. being able to import dependency types like ApexCharts
3. having a build system handle compression and optimizations, so maintainers can freely write code in inefficient but more readable ways
4. moving the front end 3rd party dependices out of the rust build step and into the typescript build step

[lovasoa]

I am 100% onboard with this. It's past time we get both a better developer experience, and a more solid frontend.

I think the first step towards that goal is to introduce a build + package step, while keeping as much of the code unchanged as possible. Ideally after this first step we should be able to run things like npm run dev -- examples/official-site to work on SQLPage with live reload, npm test to run the full test suite (rust + frontend) with unified and minimal reporting (very useful for agents), npm run build to build everything. Maybe we could switch to a unified tool like https://rsbuild.rs/ which could also replace biome. The goal for this first step would be to improve the build infrastructure, and maybe even to delete more lines of code than we introduce (the build system would what we do manually in build.rs).

Then once we have that, open a second pr with the typescript switch, that almost does not touch the build pipeline, just adds annotations to the frontend code. We could even strive to make this a PR with a net negative line count, replacing jsdoc annotations with inline ts annotations.

AI agents can do most of the migration, but from experience, they have a tendency to very quickly overbloat this kind of projects, trying to keep backwards compatibility in places that do not make sense, and ending with overcomplicated designs. If you do it, please keep your agent on a tight leash, maybe even with an explicit goal of ending on a diff that is a net negative line of code count, even if that needs making compromises.

[lovasoa]

Some ideas for next steps that a good build infrastructure would allow:

• always up to date documentation:
  • I'd love our configuration.md to move to a page on the official site that is autogenerated from the rust configuration datastructure, so that it's always up to date
  • documenting components directly from comments at the top of handlebars files instead of inside .sql migrations
  • documenting sqlpage functions directly from the rust source code
  • writing component examples as .sql files, and automatically turn them into browser tests, with custom assertions
• producing a JSON Schema for sqlpage.json that's always in sync with the rust code
• formatting and minimizing the builtin .handlebars components. Currently the components include many whitespaces that are useful when developing, but waste network bytes when serving large pages (this one may not be worth it, we would need to measure the actual whitespace footprint after compression first)
• PR previews (rendering the entire documentation site as static pages and serving them on each PR), very useful for frontend PRs
• tracking frontend byte size in tests, so that an innocent looking PR that accidentally introduces a super heavy dependency turns the CI red