[mangyan1]

Sync upstream/develop into develop, resolving every conflict so fork behaviour is preserved.

Merge commit 7808c760 — parents b3aa6ed4 (fork develop) + 3862b75e (upstream/develop tip). Regular merge, ancestry preserved: no squash, no rebase (FORK.md:75). Merge base da314cfd (the previous sync), so this brings in 5 upstream commits:

• 3862b75e small fixes — access-list create/update password validation, hooks rollback?.(), redirection-host forward_scheme $scheme, certificate/ip_ranges interval guards, schema tweaks
• a81bdd58 update nextcloud aio defaults — setup.js gains npmplus_upstream_compression: true
• b511e151 update aws-lc version to v5.11.0 — merged to no diff: the fork already carries this via 2fe4eae3
• e5a2036e dep updates — deferred, see judgement call 1
• eb30ed06 Update caddy Docker tag to v2.11.6

Judgement calls

1. Dependency files and lockfiles kept fork-side

backend/package.json, frontend/package.json, backend/pnpm-lock.yaml, frontend/pnpm-lock.yaml restored to the last-green develop state.

Every dep bump in upstream e5a2036e is younger than the fork's 7-day minimumReleaseAge window (cutoff 2026-09-26):

package	published	ages past
@tabler/core 1.6.1	2026-09-28	Oct 5
mysql2 3.24.5	2026-09-29	Oct 6
@biomejs/biome 2.5.15	2026-09-30	Oct 7
pg 8.23.1	2026-09-30	Oct 7
liquidjs 10.30.0	2026-10-01	Oct 8
vite 8.3.2	2026-10-01	Oct 8
@tanstack/react-query 5.104.1	2026-10-02	Oct 9

This follows the documented fix pattern (AGENTS.md Incident 2, :1197): restore the last-green manifests and lockfiles, never relax the policy, let the dependency-updates workflow age them in — do not hand-bump early. Verified with registry publish dates, not guesswork: taking any of these trips ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION on install.

2. Access-list password validation — upstream's create check adopted, fork's update check kept

Upstream 3862b75e adds blank-password rejection on create (a genuine gap: create had no equivalent of update's masked-password semantics, so a blank password would insert an empty credential) and a weaker version on update. Resolution:

• Create: upstream's check adopted, restyled to the fork's localized error pattern — message_i18n: "error.access.password-required" (key already exists; AccessListModal.jsx already maps it).
• Update: the fork's richer check kept — existingUsernames Set so a blank masked password keeps an existing credential while a rename still requires one. Covers everything upstream's update check does.
• New regression test: a blank password on create rejects before inserting the list or any credentials in backend/test/access-list-recovery.test.js, pinning the create-side check against a future sync dropping it.

3. Hooks — upstream's one-liner taken

All six (useAccessList, useDeadHost, useProxyHost, useRedirectionHost, useStream, useUser): upstream's onError: (_, __, rollback) => rollback?.(), replaces the fork's explicit typeof rollback === "function" guard. Semantically identical.

4. RedirectionHostModal.jsx kept fork-side

Upstream drops "auto" from the forward_scheme enum (schema + new-host default now $scheme). The fork's modal line is strictly richer: it also migrates legacy "auto" values to "$scheme" on edit, so existing rows survive the enum change. redirection-scheme.test.js already pins the "auto" → "$scheme" rendering, and the upstream new-host default auto-merged cleanly.

5. caddy/Dockerfile — fork's source build kept, version bumped to v2.11.6, pin set dropped

Upstream's eb30ed06 only moves the official caddy:2.11.4 binary tag to 2.11.6. The fork builds caddy from source via xcaddy — that design stays, with ARG CADDY_VERSION bumped v2.11.4 → v2.11.6.

The first CI run of caddy.yml failed — cel-go-0.29.patch no longer applied (2 out of 2 hunks ignored). Investigation showed caddy 2.11.6 upstreamed the fork's exact fix: both Interpretable → InterpretableV2 changes are native, cel-go moved to the new cel.dev/cel-go module (v0.32.0, newer than the fork's v0.30.0 pin), and 2.11.6's own go.mod ships every fork pin at or above the fork's version:

module	fork pin	2.11.6 ships
cel-go	github.com/google/cel-go v0.30.0 + patch	cel.dev/cel-go v0.32.0, patch native
x/crypto	v0.56.0	v0.57.0
x/net	v0.57.0	v0.59.0
chi	v5.3.0	v5.3.2
compress	v1.18.7	v1.20.1
otel	v1.45.0	v1.46.0
otel/log	v0.21.0	v0.22.0 (CVE-2026-81871 fix included)
grpc	v1.83.2	v1.83.2

So cel-go-0.29.patch is deleted, all --replace pins and their ARGs are removed, and the patch's path triggers are dropped from caddy.yml (commit d23f79f4). The pin apparatus was a workaround for 2.11.4's stale deps, not a permanent fixture; source-check.sh still runs govulncheck over the actual compiled module set, and a future red there re-adds only the single pin needed. XCADDY_SKIP_CLEANUP=1 stays — source-check.sh expects the retained build directory.

Proven locally before the CI re-run: caddy version → v2.11.6; source-check.sh passes (govulncheck: 0 reachable vulnerabilities, upstream caddyhttp + tracing tests green); CI's exact Trivy gate (--severity MEDIUM,HIGH,CRITICAL --exit-code 1) on the built image: 0 findings.

Also in this diff (upstream, taken as-is)

• backend/internal/certificate.js, backend/internal/ip_ranges.js: interval-exists guards
• backend/setup.js: nextcloud aio default npmplus_upstream_compression: true
• backend/schema/: forward_scheme enum drops "auto", examples updated

Local verification (docker CI-replica, pnpm 11.22.0, strict && chaining)

• backend: frozen-lockfile install clean under the supply-chain policy, biome ci, validate-schema, 227/227 tests (incl. the new create-path test)
• installer-recovery (28 OK), crs-observation (5 OK), crs-control (16 OK), heal-migration (6 OK), security-invariants ok, upstream-sync contracts (10 OK)
• frontend: frozen install, biome ci, sort-locale no-diff, typecheck, tests, vite build
• caddy (after the pin-drop fix): full builder + image build, caddy version v2.11.6, source-check govulncheck clean, upstream caddyhttp/tracing tests pass, Trivy MEDIUM+ gate 0 findings
• lockfiles byte-identical to develop; no conflict markers; merge commit has both parents

Not touched, deliberately

• caddy-fmt.yml still SHA-pins the official caddy:2.11.4 image for formatting only; the Caddyfile is unchanged and stays green. Bumping the fmt pin is cosmetic — left out of this sync.
• The remaining --replace-era ARGs and comments in the builder are gone entirely rather than kept "in case" — the govulncheck gate re-adds a pin when one is actually needed.