Popular v0.10.0

Added

• scripts/starter-content.py, the companion to the setup wizard: it copies
  the theme's starter content (a post, an event, an organizer, a speaker, a
  venue, the handbook and runbooks) into a new site, never overwriting anything
  that is already there.
• The wizard can write an Astro site that consumes the npm package, not only
  one that vendors this repo: --astro-model package writes
  popular.config.ts, a package.json pinned to the current release, a
  one-line src/content.config.ts, and an astro.config.mjs using the
  integration. The result is a small repo that updates with npm update rather
  than by re-copying files. --astro-model template (the default, and what an
  existing site detects as) is unchanged.
• The setup wizard asks for a brand colour, optionally. One hex is enough:
  the theme derives badges, tags, hovers and link states from it, so answering
  #fa023c writes [params.brand].primary (Hugo) or BRAND.primary (Astro)
  and the whole site follows. Skipping it writes nothing at all and leaves the
  default palette in place, which keeps a first run adoptable without --force.
  Answers are validated as #rgb or #rrggbb, a new color question type in
  the shared schema.
• A preview banner for generators (partials/preview-bar.html ⇄
  components/PreviewBar.astro). Set params.previewMode / SITE.previewMode
  and the page carries a fixed "this is a preview" bar, with an optional note
  for things like an expiry. It is meant for a tool that renders a site on
  someone's behalf and shows it in an iframe. Nothing the setup wizard writes
  into a real site's config sets the flag, and CI in both repos fails if the
  banner turns up in a build that did not ask for it.
• The setup wizard now writes everything a GitHub Pages deployment needs.
  Answer the site-URL question with a project-page URL
  (https://you.github.io/my-community/) and scripts/setup.py writes a site
  that works there:
  • Astro gains a generated astro.config.mjs carrying site and base.
    Astro needs the origin and the subpath as separate keys and nothing wrote
    base before, so a project-page site 404'd every internal link. They are
    derived from the single base_url answer, so the schema is unchanged and
    no one is asked the same thing twice.
  • Both frameworks gain .github/workflows/deploy.yml, a parameterless
    GitHub Pages workflow (everything that varies lives in the config the
    wizard already wrote). It is skipped when the site already has workflows
    of its own, so it never fights an existing deployment. Set Settings ->
    Pages -> Source: GitHub Actions once, and pushes to main publish.
• Astro: popular-markdown.mjs, the markdown hooks (lazy images, base-aware
  links) as a proper integration in the template model, matching what the npm
  package already does. Because an integration receives the resolved config,
  astro build --base /elsewhere/ now applies to markdown bodies too, where the
  old config-file hook silently kept the old base.

Changed

• The Astro demo deployment builds each demo with Astro's base instead of
  rewriting the built HTML with sed. The rewrite predated base support and
  could never reach the absolute URLs, so a deployed demo's canonical,
  og:image and JSON-LD all pointed at the site root. Both the Pages workflow
  and the Netlify preview build now run scripts/build-sites.mjs, so a preview
  cannot differ from production.
• The preview banner can be switched on from the environment, for a
  generator that owns the build but not the config: HUGO_PARAMS_PREVIEWMODE_NOTE
  (Hugo) or POPULAR_PREVIEW_NOTE (Astro). Setting either enables the banner and
  supplies its note.