docs: document ocis-workflows in the image lifecycle

[DeepDiver1975]

Why

owncloud/ocis-workflows joined the organisation
but is absent from this document, which is the authoritative description of how our images
are built, tagged, scanned and published — and is written primarily for the security team.
An image the security team cannot find here is an image they cannot assess.

It needed more than a name appended to the repo list. It is the first extension image
in the org — deployed alongside owncloud/ocis rather than instead of it — and the first
to ship two deployables in a single image, so §1's topology and §2's build strategies
both needed real text.

What changed

§	Change
1	New "extension image" category; the two-deployables arrangement and the /web/apps/workflows handoff; repo list and inheritance diagram updated
2b	Noted as a second consumer of docker-build-native.yml
2d	New — the three-stage frontend + backend build, and the Go-stdlib consequence below
2 (build args)	New row: same arg scheme as ocis, but only GIT_REF=main is used today
3	New tagging row — rolling-only, no version tags
5b, 5c, 5f	apk upgrade wording covers both Alpine images; noted that the weekly rebuild is also how upstream application changes land here; §5f records that there is nothing to bump
6	Push trigger and the /healthz smoke test
7	apk upgrade row extended; new row for Go stdlib CVEs in from-source images
8	Repository link

Two things the security team should know

Both are new prose, not just a name in a table:

It is rolling-only. Upstream cuts no semver releases yet, so there is no version matrix
and latest tracks upstream main. A deployment that needs a fixed target must pin the
date or sha- tag. This is called out in §3 rather than left to be inferred from the
absence of version tags.

A stale Go toolchain digest is a CVE exposure, and it is not obvious. Because the Go
stage compiles the shipped binary, the Go standard library linked into that binary is
whatever the pinned golang:*-alpine digest provides. A stale digest surfaces as stdlib
findings against /usr/local/bin/app — not against the OS layer, where you would look
first — and the fix is bumping the digest, not adding a .trivyignore entry.

This is not hypothetical. It is exactly why ocis-workflows had never published a single
image: its pinned digest was Go 1.26.5, and eight HIGH stdlib CVEs failed the Trivy gate on
every run since the repo was created. See
owncloud-docker/ocis-workflows#5,
which fixes it. This property already applies to ocis and was undocumented, so §2d and
the new §7 row are written to cover both.

Verification

Prose only — no workflow or config in this repo changes. Every claim added was checked
against the code rather than inferred from the existing text:

• The three build stages, CGO_ENABLED=0, the non-root uid, both COPY --from targets and
  the apk upgrade line: read from ocis-workflows/Dockerfile.multiarch.
• The prepare job resolving main HEAD into GIT_SHA/REVISION, the latest /
  <YYYYMMDD> / sha-<short> tag set, the weekly 0 0 * * 0 cron, the non-PR push
  condition and the port-9109 /healthz smoke test: read from that repo's main.yml.
• The Trivy gobinary behaviour: observed in that repo's CI logs, both before the fix
  (8 HIGH against usr/local/bin/app) and after (0 on both architectures).

No existing repo's description was modified.

🤖 Generated with Claude Code