ci: drop unused scheduled workflows (security-scan, template-sync) (#74)

* ci: drop unused scheduled workflows, quiet Dependabot to monthly

The weekly security-scan and template-sync workflows generated churn no
one acts on:

- security-scan.yaml ran pip-audit on a schedule and dumped a JSON report
  into the Actions tab that nobody monitors. It is redundant with GitHub's
  native Dependabot security alerts. The on-demand `tox -e security` env
  is kept for local CVE scans.
- template-sync.yaml is a no-op in the template repo itself and does a
  whole-tree merge into forks that conflicts on pyproject.toml/README for
  any customized plugin. Pulling template changes is now a deliberate
  manual step.

Also moves Dependabot version updates from weekly to monthly to cut the
patch-bump PR noise that fights the 7-day `exclude-newer` resolver window.

Docs updated to match (github-workflows.md, github-repository-settings.md).

* docs: document the scaffold-rename workflow and its PR check

Review of #74 found the workflow doc undercounted: there are three
workflow files (test, scaffold-test, release), not two. The
scaffold-rename job was never documented even under the old count.

- github-workflows.md: correct "two" -> "three" and add a Scaffold
  Rename Workflow section.
- github-repository-settings.md: note the per-PR `scaffold` check so it
  can be added to required status checks.

* ci: keep Dependabot on weekly

Revert the weekly -> monthly change. The grouped weekly cadence is at
most one PR per week and keeps dev deps current; the noise it adds is
acceptable. Security updates are unaffected by the interval either way.

* docs: note scaffold workflow manual dispatch and default-token bucket

Two completeness fixes flagged in #74 review:
- github-workflows.md: scaffold-test.yml has a workflow_dispatch
  trigger; add the missing Manual dispatch bullet.
- github-repository-settings.md: scaffold-test.yml also runs on the
  default GITHUB_TOKEN with no secrets; widen the sentence that only
  named test.yml so the no-secrets bucket is complete.

Author: TKaltofen

.github/workflows/security-scan.yaml

@@ -13,7 +13,7 @@ The release workflow is the only one that needs secrets. Both live under **Setti
 | `SEMANTIC_RELEASE_TOKEN` | `release.yaml` (`github_release` job) | A Personal Access Token with `repo` write so semantic-release can tag the release and push the version-bump commit back to `main`. The default `GITHUB_TOKEN` cannot push to a protected branch, which is why a PAT is required. |
 | `PYPI_API_TOKEN` | `release.yaml` (`publish` job) | PyPI API token used by `twine upload`. Scope it to the project once the package is published for the first time. |
 
-See [github-workflows.md](github-workflows.md#setting-up-secrets) for the step-by-step on creating each token. The other workflows (`test.yml`, `security-scan.yaml`, `template-sync.yaml`) run on the default `GITHUB_TOKEN` and need no secrets.
+See [github-workflows.md](github-workflows.md#setting-up-secrets) for the step-by-step on creating each token. The test and scaffold workflows (`test.yml`, `scaffold-test.yml`) run on the default `GITHUB_TOKEN` and need no secrets.
 
 ### PyPI Trusted Publisher (modern alternative)
 
@@ -51,7 +51,9 @@ The test workflow (`test.yml`) declares a job called `test` with a matrix over P
 
 If you drop a Python version from the matrix in `test.yml`, also drop it from the required checks; otherwise PRs will block forever waiting for a check that never runs. The placeholder check rides on the `3.10` leg via an `if:` guard in `test.yml`; if you change which Python version runs that step, update the guard to match.
 
-The security scan (`security-scan.yaml`) and template sync (`template-sync.yaml`) workflows run on a schedule and do not produce per-PR checks, so they should not be added as required.
+The scaffold-rename workflow (`scaffold-test.yml`) also runs on every PR to `main` and emits a `scaffold` check. Add it too if you want the customize-step validation to gate merges:
+
+- `scaffold`
 
 ## Dependabot reviewer
 

.github/workflows/template-sync.yaml

@@ -1,6 +1,8 @@
 # GitHub Workflows
 
-This project uses four GitHub Actions workflows to automate testing, security scanning, template synchronization, and releases.
+This project uses three GitHub Actions workflows to automate testing, scaffold validation, and releases.
+
+Dependency CVE scanning is left to GitHub's native Dependabot security alerts (enable them under **Settings > Code security**), with `tox -e security` (`pip-audit`) available for on-demand local scans. Pulling later template changes into a scaffolded repo is a deliberate, manual step (fetch the template remote and cherry-pick), not an automated job.
 
 ## Test Workflow
 
@@ -14,40 +16,18 @@ This project uses four GitHub Actions workflows to automate testing, security sc
 
 **Requirements:** None. This workflow uses only public GitHub Actions and requires no secrets.
 
-## Security Scan Workflow
+## Scaffold Rename Workflow
 
-**File:** `.github/workflows/security-scan.yaml`
+**File:** `.github/workflows/scaffold-test.yml`
 
 **Triggers:**
-- Scheduled: Every Monday at 9:00 AM UTC
-- Manual dispatch (can be triggered from any branch)
-
-**Purpose:** Performs CVE vulnerability scanning on the local package using pip-audit via tox. The workflow builds the package and scans its dependencies for known vulnerabilities.
-
-**Requirements:** None. Uses only the default `GITHUB_TOKEN` with read permissions.
-
-## Template Sync Workflow
+- Push to `main`
+- Pull request to `main`
+- Manual dispatch
 
-**File:** `.github/workflows/template-sync.yaml`
+**Purpose:** Copies the template to a scratch directory, runs `bin/customize.sh` against the copy, and runs tox on the renamed scaffold. This proves the customize step still produces a green plugin end to end. It emits a per-PR check named `scaffold`.
 
-**Triggers:**
-- Scheduled: Every Thursday at 9:00 AM UTC
-- Manual dispatch (can be triggered from any branch)
-
-**Purpose:** Keeps this repository in sync with the upstream template repository ([mloda-plugin-template](https://github.com/mloda-ai/mloda-plugin-template)). The workflow:
-1. Checks if there are new commits in the template repository
-2. If new commits exist, creates a branch `chore/template-sync-YYYY-MM-DD`
-3. Merges template changes into the branch
-4. Opens a pull request for review
-
-**Requirements:** None. Uses only the default `GITHUB_TOKEN` with write permissions for contents and pull-requests.
-
-**Note:** If merge conflicts occur, the workflow will fail and manual resolution is required. Run locally:
-```bash
-git remote add template https://github.com/mloda-ai/mloda-plugin-template.git
-git fetch template
-git merge template/main
-```
+**Requirements:** None. Uses only public GitHub Actions and requires no secrets.
 
 ## Release Workflow