Decide on a delivery mechanism for shared repo templates and tooling config

The initial scaffolding PR (#2) included a `templates/` directory (SECURITY.md, CONTRIBUTING.md, AGENTS.md, dependabot configs, pre-commit config) and a `python/pyproject-snippets.toml` (ruff/pyright/codespell/coverage config), all intended to be copied into our repos. We pulled them out of that PR because *how* we deliver these is a real design decision worth its own discussion.

The standardised *decisions* behind the Python tooling config now live in `python/STYLE.md`; this issue is about the delivery mechanism for the actual ready-to-copy files (both the repo templates and the `pyproject.toml` config).

The dominant use case is **avoiding drift** across our existing repos (operator, jubilant, pytest-jubilant, charmhub-listing-review, charmlibs, …) rather than bootstrapping new repos, which we don't do often.

Options to weigh:
- **GitHub template repository** ("Use this template") — good for new repos, but one-shot and no ongoing sync.
- **cookiecutter** — parameterised generation (handles `{{REPO}}`-style placeholders), but also one-shot; no update path for existing repos.
- **copier** — templating *with* update support, so existing repos can pull in later changes. Best fit for the drift use case, at the cost of an extra tool/dependency.
- **Documented copy-from-source** — what the PR did; simplest, but drift-prone and manual.

Decide on the approach and, if it's a separate repo/tool, set it up and migrate the template files and the Python tooling config there.

Start with python/STYLE.md, the templates/ directory, and python/pyproject-snippets.toml, then review the options and the earlier scaffolding PR (#2). Compare the delivery approaches against drift across the listed existing repositories. Done means an approach is decided, any separate repo or tool is set up, and the template files and Python configuration are migrated.

Written by the indexing model from the issue text.