ci: pull the indicator count, and render the banner in the same job

[kingchenc]

Why

The indicator count is decided in wickra-lib/wickra and appears three times in profile/README.md — twice in prose and once as the ?v= cache-buster on the banner image.

Today it arrives by push: that repository's sync-about.yml clones this one with a personal access token and commits the number. That token carries write access to four repositories, Administration: write on wickra and admin:org. It is the only repository-level secret in the organisation and exists for no other reason.

A schedule is also the only trigger that can work here — the number changes in the other repository, so a push here is not the event that makes this profile wrong. Hourly at :43, clear of refresh-badges at :17 and refresh-social at :37.

The banner is rendered in this job, not left to banner.yml

This is the part that would have broken silently.

banner.yml fires on a push to profile/README.md. A push made with GITHUB_TOKEN does not start workflows — only the personal access token did. Keeping the split would have frozen the banner the moment the token went away: the README would carry the new number, the image would keep the old one, and every check would stay green.

So this job regenerates it directly. banner.yml still covers a hand-edited README and manual dispatch; it is simply no longer load-bearing.

The cache-buster is bumped for the same reason

GitHub proxies the raw image through Camo. A regenerated banner at an unchanged URL keeps serving the old picture.

Nothing bumped it before — sync-about.yml patches the prose count only, so the ?v= has been moving only when someone edited it by hand.

Guard

The parse refuses a count under 100 — what a moved re-export block or a truncated fetch produces. Without it, a partial response silently replaces a correct number with a wrong one.

Verification

The derivation matches sync-about.yml's. Checked three ways at 514: local source, grep -c '^mod ', and a live fetch through raw.githubusercontent.com. Both sed expressions were dry-run against the current profile/README.md and hit exactly the four occurrences (line 2 cache-buster, lines 31, 73, 84 prose).

Same workflow already merged and verified live in wickra-docs (#104) and webpage (#72): each run reads 514 and reports nothing to commit.