Introduce jspecify.dev/api.

[cpovirk]

It redirects to jspecify.dev/docs/api, which in turn redirects to jspecify.dev/docs/api/org/jspecify/annotations/package-summary.html.

"jspecify.dev/api" is not dramatically shorter, but I figure that every bit helps. This also follows some precendent from some Google libraries, including guava.dev/api and truth.dev/api. We could consider further following Guava precedent by adding jspecify.dev/Nullable, jspecify.dev/NullMarked, etc.

As for the implementation approach: Gemini says:

Here is why a static HTML redirect in docs/static/ is the most correct and idiomatic approach for this project:

1. Why not @docusaurus/plugin-client-redirects?

While Docusaurus has an official redirect plugin (@docusaurus/plugin-client-redirects), that plugin validates during the static SSR compilation step that every destination (to) path matches an internal route known to Docusaurus. Because your Javadoc at /docs/api/ is copied into the output folder by Gradle (copyDocs) after Docusaurus completes its build, the redirect plugin would reject /docs/api/ as an unrecognized route.

2. How docs/static/api/index.html works on GitHub Pages

• Docusaurus static asset handling: Any file placed in docs/static/ is copied as-is to the root of the output build/ directory during docusaurus build (or ./gradlew buildDocs).
• GitHub Pages static hosting: Because GitHub Pages is purely static hosting (and .nojekyll disables Jekyll redirect plugins), client-side HTML redirects using <meta http-equiv="refresh"> combined with JavaScript are the standard mechanism.
• When a user visits https://jspecify.dev/api (or /api/), GitHub Pages serves build/api/index.html, which immediately redirects the browser to /docs/api/.

And when I asked about avoiding the "Javadoc... is copied into the output folder by Gradle (copyDocs) after Docusaurus completes its build" problem by having Gradle copy its ouputs before Docusaurus runs, Gemini said:

Here is a breakdown of what would happen if Gradle copied them earlier, why it wouldn't help with Docusaurus plugins, and the architectural tradeoffs:

---

1. It wouldn't change how Docusaurus plugins (like redirect) behave

In Docusaurus, the internal routing table is built strictly from React and Markdown source components (docs/, blog/, src/pages/).

• Neither existing HTML files in the output directory (build/) nor raw assets in static/ are ever registered as internal Single Page Application (SPA) routes.
• Therefore, even if Javadoc files were present before Docusaurus started compiling, plugins like @docusaurus/plugin-client-redirects, sitemap, and the SPA broken-link checker would still treat /docs/api/ as an unmanaged external asset path rather than an internal route.

---

2. Option A: Copying into docs/build/ before Docusaurus runs

If Gradle copied Javadoc into docs/build/docs/api/ before executing npm run build:

• Result: docusaurus build clears the target output directory (build/) by default at the very start of its compilation step. Anything placed in build/ before Docusaurus runs would be instantly wiped out.

---

3. Option B: Copying into docs/static/docs/api/ before Docusaurus runs

To make Docusaurus preserve and copy the files itself, Gradle would have to output generated Javadoc into Docusaurus's source asset directory (docs/static/docs/api/). While this would technically work, it introduces significant downsides:

• Polluting the source tree with build artifacts: You would be writing hundreds or thousands of generated HTML/CSS files directly into your source directory (docs/static/). This clutters IDE indexing, file searches, and working directory status, requiring new .gitignore rules to ignore the generated subfolder.
• Risk of serving stale Javadoc: If a developer ran npm start or npm run build directly without running Gradle first, they might silently serve stale Javadoc leftover in docs/static/ from a build weeks ago without realizing it.
• Slower Docusaurus builds: During compilation, Webpack enumerates and copies every single asset in static/ over to build/. Forcing Webpack to process thousands of Javadoc files slows down Docusaurus's build. Letting Gradle handle the Javadoc file copying directly from one build folder to another is much faster and more efficient.
• The only pro: If Javadoc were in docs/static/docs/api/, it would be accessible during local development when running npm start. However, because you can already preview everything cleanly by running ./gradlew buildDocs && npm run serve (as documented in your README.md [cpovirk note: at least after https://github.com/jspecify/jspecify/pull/847!\]), polluting the source tree is not worth this minor benefit.

Conclusion

Keeping your source tree (docs/) strictly separated from build outputs (docs/build/) and having Gradle's copyDocs task assemble the final site post-build is the cleanest, most performant, and most idiomatic architecture.