8.2 line: three CVEs in released v8.2.0; stable-8.2 still short of the grpc fix

## Request

Two things for the 8.2 line:

1. **Bump `google.golang.org/grpc` from v1.83.0 to v1.83.1 on `stable-8.2`.** This is the one
advisory in this report that is *not* yet fixed on the branch.
2. **Cut an 8.2.1 patch release.** `v8.2.0` (2026-08-10) is the only 8.2 release and it carries
the `latest` tag, so every fix already merged on `stable-8.2` is currently unreachable for
anyone tracking 8.2.

## Why

Our Trivy gate in [owncloud-docker/ocis](https://github.com/owncloud-docker/ocis) scans the `ocis`
binary inside the image it just built. Three advisories currently apply, and the released `v8.2.0`
is below the fix version for all three:

| Advisory | Dependency | `v8.2.0` (released) | Fixed in | `stable-8.2` today |
| --- | --- | --- | --- | --- |
| CVE-2026-56854 (CRITICAL) | `golang.org/x/crypto` | v0.54.0 | 0.55.0 | **v0.55.0** ✅ |
| CVE-2026-46603 (HIGH) | `golang.org/x/image` | v0.44.0 | 0.45.0 | **v0.45.0** ✅ |
| CVE-2026-84304 (HIGH) | `google.golang.org/grpc` | v1.82.1 | 1.83.1 | v1.83.0 ❌ |

Every version above was read directly from `go.mod` at the respective ref, not inferred.

- CVE-2026-56854 — `golang.org/x/crypto/ssh`: authentication bypass due to unenforced
source-address restrictions
- CVE-2026-46603 — `golang.org/x/image/vp8l`: denial of service via excessive memory allocation
- CVE-2026-84304 — gRPC-Go, affecting versions prior to 1.83.1

## What is already done, and the one gap

`stable-8.2` picked up two of the three fixes as normal maintenance, so most of this is just a
release-timing ask:

- #12775 (`chore: [stable-8.2] bump go and web packages`, 2026-08-12) took grpc v1.82.1 → v1.83.0
- #12806 (`security: bump golang.org/x/image to v0.45.0`, 2026-08-18) took x/image v0.44.0 → v0.45.0
- #12848 (`chore(deps): bump golang.org/x/mod to v0.40.0`, 2026-08-26) also took x/crypto v0.54.0 → v0.55.0

The gap is grpc. The bump in #12775 landed on v1.83.0, and CVE-2026-84304 is only fixed in
v1.83.1 — so `stable-8.2` is one patch short. For comparison, `master`, `stable-8.0` and
`stable-8.1` all already sit on v1.83.1.

## How the other lines compare

| Line | Latest release | Affected by the three above? |
| --- | --- | --- |
| 8.0 | v8.0.8 (2026-08-21) | no — ships x/crypto v0.55.0, x/image v0.45.0, grpc v1.83.1 |
| 8.1 | v8.1.0 (2026-07-06) | **yes, all three** — see #12810 |
| 8.2 | v8.2.0 (2026-08-10) | **yes, all three** — this issue |
| master | — | no |

8.0 is the only line whose newest release is clean. 8.1 is a pure release-cadence problem already
tracked in #12810 (`stable-8.1` is fully fixed, just never tagged); I have added these three
advisories to that thread. 8.2 is filed separately because it needs an actual dependency bump
first.

## Downstream impact

Our Trivy gate scans the built binary, so `owncloud/ocis:8.2`, `:8` and `:latest` cannot be
published green while `v8.2.0` is the build input. The only way to keep publishing them would be
to carry all three advisories as suppressions in
[`v8/8.2/.trivyignore`](https://github.com/owncloud-docker/ocis/blob/master/v8/8.2/.trivyignore),
which is exactly the kind of thing we would rather not ship on the `latest` tag. That file is
currently empty and we would like to keep it that way.

One caveat on the evidence: the failure we can *point at* is the 8.1 leg of
[run 34207664511](https://github.com/owncloud-docker/ocis/actions/runs/34207664511/job/102000945939),
which reports exactly these three advisories against the 8.1.0 binary:

```
usr/bin/ocis (gobinary)
Total: 3 (HIGH: 2, CRITICAL: 1)

golang.org/x/crypto CVE-2026-56854 CRITICAL v0.52.0 -> 0.55.0
golang.org/x/image CVE-2026-46603 HIGH v0.43.0 -> 0.45.0
google.golang.org/grpc CVE-2026-84304 HIGH v1.81.1 -> 1.83.1
```

The 8.2 leg of that same run never reached its Trivy step — our build matrix had `fail-fast` at
its default, so the 8.1 failure cancelled it. The 8.2 exposure above is therefore derived from
`go.mod` at `v8.2.0` rather than from an observed scan. I am fixing the `fail-fast` behaviour on
our side so the 8.2 leg reports its own status, and will post that scan here once it runs.

## On reachability

Trivy resolves module versions from the Go binary's build metadata and does not do reachability
analysis, so it does not claim any of this is exploitable in oCIS — `golang.org/x/crypto/ssh` in
particular may well never be reached. That does not change the gate's behaviour, though, and the
two honest ways out are a version bump or a published VEX statement (Trivy suggests the latter
itself in the scan output). A bump seems much simpler here, especially as two of the three are
already done.

## A note on the channel

`SECURITY.md` asks that vulnerabilities not be filed as public issues, and I want to be explicit
that I do not think this is one: all three advisories are already public, all three sit in public
third-party dependencies, two are already fixed on a public branch, and the actual ask is a
one-line dependency bump plus release timing. Nothing undisclosed is revealed here. Happy to move
this to security.owncloud.com if you would prefer.

## If 8.2 is not receiving patch releases

If the intent is that 8.2 users wait for the next feature release rather than an 8.2.1, please
just say so — that is a fine answer, and we would plan the `latest`/`8.2` tag handling around it
instead.

Start with go.mod on stable-8.2 to verify the google.golang.org/grpc version, then review the existing 8.2 release and tagging process. Confirm that v8.2.1 is published and that the resulting ocis image passes the Trivy gate without adding suppressions to v8/8.2/.trivyignore.

Written by the indexing model from the issue text.