Build Open API static site on dev API runs

[pratishta]

Description

The pre-commit hook for this helps us keep the Open API documentation and the html file for the static site in sync. However, we get a lot of merge conflicts when multiple developers are working on small items to update the documentation. this was done under the premise that we truly needed the site tracked in source. After talking about it further, it makes more sense to remove the file from source entirely. Instead, it should be generated as part of the development and production API builds.

We could move this automatic build to when a PR is merged to main so that devs don't have to remember to build and also it will only happen once. This could be a good chance to start working on the CI for this repo by introducing a small GHA workflow. I'm looking at EDDE's example

The acceptance criteria have been updated to reflect this change in strategy.

Acceptance criteria

• [ ] Add the open api build step to the npm run dev command
• [ ] Remove the index.html from source and .gitignore it
• [ ] Note in the README that redoc:dev has the latest documentation updates while npm run dev has the state of the documentation from when the server was run. It is possible to run both commands simultaneously because the run on different ports.
• [ ] Remove the redoc:build step from the pre-commit hook because it's no longer necessary

[TangoYankee]

We should take this opportunity to perform a suite of code quality checks:

• [ ] build the openapi index.html
• [ ] lint
• [ ] test
• [ ] test:e2e

Another example of this approach is on the main branch of labs-zap-search ('main' is a temporarily a feature branch while we transition away from gitflow in that repo). This is relevant because we'll be using heroku to deploy the zoning api.

EDIT: I made a separate ticket for the code quality stuff (#275 ). We'll keep this one focused on redoc:build

[TangoYankee]

Commit actions git-auto-commit-action add and commit

[TylerMatteo]

This all sounds good to me. @TangoYankee thanks for making the tickets for code quality and deployments and apologies for not documenting that work myself sooner. As for generating the OAS docs, I have some concerns about disconnected the generation from the actual changes to the yaml but I can appreciate the headaches caused by the current approach. Let's try this new approach and see how it goes.