chore(docker): derive the Mago version from the webware-tools pin

[tyrsson]

What

Removes the literal Mago version from this repository's tooling container.

Dockerfile carried ARG MAGO_VERSION=1.47.3 and compose.yml passed it as a build arg. That value had drifted from the pin mago actually enforces here: mago.toml in this package extends vendor/webware/webware-tools/mago.toml, whose version = "1.49.0" (webware-tools tag 1.0.0-beta.2) is what mago reads and warns about.

How

The build now resolves the version from the pin itself:

1. COPY composer.lock into the image (the lock only — the build context has no application files).
2. Read the webware/webware-tools revision out of the lock.
3. Fetch that revision's mago.toml from raw.githubusercontent.com (the revision is a commit SHA, so it is immutable).
4. Read version = "..." and install exactly that Mago release.

compose.yml no longer passes MAGO_VERSION. The build fails loudly if the lock does not pin webware/webware-tools, or if the centre file has no version pin.

Why

The version now has exactly one home: version = in webinertia/webware-tools/mago.toml. A Mago bump in the centre reaches this container via whichever revision composer.lock requires — no per-repository sweep, and no way for the container and the config to disagree.

webinertia/.github gains a guard step that fails any build that re-introduces a literal (Dockerfile ARG MAGO_VERSION=, a compose build arg, a workflow tools: mago:<ver>, a mago.toml version =, or a version-pinned mago schema URL). Merge order only matters for other open PRs in this repository: a PR branched from the default branch still carries the literal and would be reddened by the guard until this lands. This PR itself passes either way.

Verification

• The derivation block was extracted from the edited Dockerfile and executed against this repository's composer.lock: resolves 8c4deefee3e09ff30d2af3fde6250045134dfa4e → 1.49.0.
• sh -n on the full RUN body: clean.
• The guard's patterns over this tree: no Mago version literal remains.

Also in this PR: the README CI badge

The badge pointed at .github/workflows/continuous-integration.yml, which this repository does not
have — it was removed when the repository moved to the organization's required workflow — so the
badge has been returning 404.

It now uses GitHub's synthetic route for a required workflow, which resolves and reports the live
state (200, <title>Required CI - passing</title>):

https://github.com/webinertia/webware-admin/actions/workflows/required/webinertia/.github/.github/workflows/org-required-ci.yml/badge.svg

The route spells out the coordinates of the config repository — required/<owner>/<config-repo>/<path>
— because that is where the workflow file lives. A plain continuous-integration.yml path cannot
work: no such file exists here.

Files changed

Dockerfile
README.md
compose.yml

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!