Add default esbuild loaders for common asset types referenced in CSS

[bcomnes]

This issue was originally identified in voxpelli/voxpelli.github.com#32

Problem

When CSS references an image or font file (e.g., background-image: url(./img/loader.gif)), the DomStack build crashes with an opaque esbuild error because no loader is configured for that file extension. This is a first-run experience problem -- a user's very first build fails if their CSS references any non-CSS, non-JS asset, and the error message provides no guidance on how to fix it.

Reproduction

/* src/global.css */
.loading {
  background-image: url(./img/loader.gif);
}

Build fails with:

Error building JS+CSS with esbuild
  No loader is configured for ".gif" files: src/img/loader.gif

This also applies to .png, .jpg, .svg, .webp, .woff2, .ttf, and any other asset type referenced from CSS.

Current behavior

The esbuild configuration in lib/build-esbuild/index.js builds entry points for styles and scripts but provides no default loaders for assets. The esbuild.settings.js extension mechanism exists but provides no guidance when things break.

Expected behavior

Common asset types referenced in CSS should work out of the box, just as they do in Vite, Next.js, Astro, or any other modern build tool.

Workaround

Create src/esbuild.settings.js and manually configure loaders. Problems: user must know the file exists, know esbuild's loader concept, and add every extension individually.

Proposed solution

Option A (recommended): Ship default loaders for common asset types

const defaultLoaders = {
  // Images -- inline as data URLs
  '.png': 'dataurl',
  '.jpg': 'dataurl',
  '.jpeg': 'dataurl',
  '.gif': 'dataurl',
  '.svg': 'dataurl',
  '.webp': 'dataurl',
  '.avif': 'dataurl',
  '.ico': 'file',

  // Fonts -- output as separate hashed files
  '.woff': 'file',
  '.woff2': 'file',
  '.ttf': 'file',
  '.eot': 'file',
  '.otf': 'file',
};

This is fully backwards-compatible: sites without esbuild.settings.js get the defaults (currently they get nothing), and sites with esbuild.settings.js can override via ...opts.loader.

Option C: Better error messages (minimum viable improvement)

Catch the esbuild error for unknown file types and produce an actionable error message pointing users to esbuild.settings.js.

Recommendation: Option A is strongly preferred. Option C should be done regardless as a safety net.

Real-world impact

This affects every DomStack site whose CSS references images or fonts — which is the majority of real-world websites. Common patterns: background images, @font-face, custom cursors, list-style images.