Replace the version-specific app image with a generic release/master foundation #66

Goal

Implement the next focused increment of #47: remove the version-specific .docker/app/Dockerfile.35 architecture and make the existing app Dockerfile capable of building both release images and a development image that follows Nextcloud Server master.

This issue is about the image foundation only. It must not define the final publication/tagging workflow from #62.

Architecture

Use one generic .docker/app/Dockerfile.

The image must support two explicit source modes:

• release: keep the Nextcloud payload supplied by the selected official Nextcloud base image;
• daily: replace the Nextcloud payload with a verified upstream daily archive, such as latest-master.tar.bz2.

The base image must remain configurable independently from the upstream server payload so the development channel is not tied to a Nextcloud major.

The existing Compose environment remains the deployment definition. It may map its existing NEXTCLOUD_VERSION setting to the generic base-image input, but this issue must not introduce another Compose stack.

Development source

For daily mode:

• require an explicit upstream daily URL;
• fetch the corresponding upstream SHA-512 file;
• verify the archive before extracting it;
• derive the archive filename from the URL rather than hard-coding a major/version;
• do not assert an expected future Nextcloud major;
• prepare /usr/src/nextcloud in the same shape expected by the official image entrypoint.

The development channel follows Nextcloud Server master, not “the next major”.

Shared runtime

Release and daily modes must share the same LibreCode runtime additions and PHP configuration.

Do not add LibreSign-specific tooling.

Pin external build helpers where practical instead of downloading mutable latest assets.

Validation

Before this foundation can be used for publication:

• the existing release build must continue to pass vulnerability scanning and the app runtime acceptance test from Add runtime acceptance tests for the Nextcloud app image #49;
• a development build using latest-master.tar.bz2 must build from the same Dockerfile;
• the development build must pass the same Trivy policy;
• the development build must pass the same Bats runtime acceptance test;
• validate both amd64 and arm64.

CI validation may use a dedicated development-image workflow, but it must not publish development tags in this issue.

Remove obsolete architecture

Remove:

• .docker/app/Dockerfile.35;
• the old Nextcloud-35-specific publication workflow.

Do not preserve the historical :35 publication path; #52 found no active consumer requiring that alias.

Out of scope

Do not implement in this issue:

• :master-fpm publication;
• stable/full-version publication tags;
• cache/tag policy from ci(images): publish scanned Nextcloud development channels #62;
• a second Compose environment;
• new Dockerfiles per major;
• web/Redis integration scenarios.

Acceptance criteria

• one app Dockerfile handles release and daily/master source modes;
• no Dockerfile is tied to a Nextcloud major;
• the current Compose build still uses the same environment-level version setting;
• daily archives are verified with upstream SHA-512;
• external PHP extension installer is pinned and verified;
• release amd64/arm64 still pass scan + runtime acceptance;
• master amd64/arm64 pass scan + runtime acceptance;
• the old Nextcloud-35 workflow and Dockerfile are removed;
• no new development image is published yet.

Relationship

Blocks the reconstruction of #62.

Parent epic: #47.