docs: normalize legacy server product name to "ownCloud Classic" (10.15)

[DeepDiver1975]

What

Normalizes the legacy ownCloud server product to its canonical name ownCloud Classic across all user-facing documentation in this repo. Version (10/11) is retained only as trailing information where relevant (e.g. "ownCloud Classic 10").

Normalized: ownCloud Server, ownCloud Classic Server, bare ownCloud 10/11, and the OC10 prose shorthand used throughout the migration guide. The Antora component title is updated from ownCloud Server to ownCloud Classic.

Why

Part of owncloud/docs#5111 — a coordinated, docs-only rebranding so the legacy product is consistently named ownCloud Classic across the owncloud / owncloud-docker orgs. Reference implementation: owncloud/docs-main#187.

Out of scope (intentionally untouched)

• xref:/include:: targets, module slugs (classic_ui, oc10-app), URLs, hostnames (oc10-telemetry, oc10130b1…), anchors
• AsciiDoc editorial comments (e.g. // this needs review for oc10 -> oc11)
• The new product names: ownCloud Infinite Scale / oCIS
• The component name: server slug (only the display title changed)

Known follow-up

The product name is still embedded in one Kerberos diagram source (modules/admin_manual/images/.../kerberos-principle.drawio.svg). Updating diagram artwork requires re-rendering and is intentionally left out of this text-only PR.

Verification

• All target variants normalized in prose/headings/title; only display text changed.
• Every xref/include/URL target byte-for-byte identical before/after.
• oCIS / Infinite Scale occurrence count unchanged.
• Standalone Antora build produces an identical error set vs master (2 pre-existing cross-component ocis: xrefs that only resolve in the aggregate build) — no new errors.
• No internal xref depends on the 13 headings whose auto-generated anchors change.

Reviewer checklist

• No xref targets / module slugs / URLs / hostnames altered
• oCIS / Infinite Scale untouched
• Version shown only as additional info ("ownCloud Classic 10")

🤖 Generated with Claude Code

[DeepDiver1975]

🤖 Automated review by Claude Code review agent.

Verdict: LGTM — clean, prose-only product-name normalization ("ownCloud Server" → "ownCloud Classic") backported to the 10.15 branch.

Checked the full diff (39 files) for any non-display-text changes and found none:

• antora.yml — only title: changed; the component name: server and version: '10.15' are untouched (xref component IDs and version routing unaffected). ✅
• README.md — link/heading display text updated to "Classic" while the anchor target #create-a-new-version-branch-for-owncloud-server is correctly left intact. ✅
• All xref: / image: / include:: targets, file paths, :page-aliases:, URLs, attribute names (e.g. :description:), marketplace-URL attributes, and code literals (config.php, oc_filecache, env vars, occ command names) — unchanged. Only human-readable text was altered. ✅

Note: migrating_to_ocis.adoc on this branch carries some pre-existing surrounding typos (e.g. "oCis", "extrernal", an absolute /ocis/next/ link) — these are unrelated to this PR and were not introduced by it; the rename edits themselves are correct and prose-only.

Required checks (Build documentation, lint) are green. No changelog in this repo (n-a).

No blocking issues.

[phil-davis]

Suggested change

	:description: This guide describes how to migrate an ownCloud Classic 10 instance to ownCloud Infinite Scale (oCIS) using the migrate-to-ocis app and its occ commands.
	:description: This guide describes how to migrate an ownCloud Classic instance to ownCloud Infinite Scale (oCIS) using the migrate-to-ocis app and its occ commands.

[phil-davis]

Suggested change

	The migration transfers users, groups, files, and shares from an ownCloud Classic 10 instance to a target oCIS instance in a series of sequential steps. The ownCloud Classic server is not modified by the migration — it remains operational throughout most of the process.
	The migration transfers users, groups, files, and shares from an ownCloud Classic instance to a target oCIS instance in a series of sequential steps. The ownCloud Classic server is not modified by the migration — it remains operational throughout most of the process.

[phil-davis]

Suggested change

	The migration works with an app to be installed on the ownCloud Classic 10 side. The app is provided by ownCloud as part of the guided migration. Please contact {oc-support-url}[ownCloud support] to get it.
	The migration works with an app to be installed on the ownCloud Classic side. The app is provided by ownCloud as part of the guided migration. Please contact {oc-support-url}[ownCloud support] to get it.

[phil-davis]

Suggested change

	=== ownCloud Classic 10
	=== ownCloud Classic

[phil-davis]

Suggested change

	This is a concise guide to running acceptance tests on ownCloud Classic 10.
	This is a concise guide to running acceptance tests on ownCloud Classic.

[DeepDiver1975]

Thanks @phil-davis — applied all 5 suggestions in ce1a2a2.

You've identified the right distinction: in these spots ownCloud Classic 10 denotes the product as the migration source / generic context, so the 10 is redundant now. I've stripped it in the migration-to-oCIS guide and the acceptance-tests intro, while keeping the genuinely version-specific references untouched (Starting with ownCloud Classic 10 in the database doc, the theming before/deprecated in 10 + upcoming ownCloud Classic 11 contrast, the WND listener, and the migration 10 → 11 steps).

For consistency I've applied the same change on the other branches carrying these lines:

• 10.16 backport: docs: normalize legacy server product name to "ownCloud Classic" (10.16) #1551 (updated)
• master: docs: drop redundant '10' from 'ownCloud Classic 10' in migration/acceptance docs #1553 (new follow-up, since master was already merged)

[DeepDiver1975]

🤖 Automated review by Claude Code review agent.

Re-reviewed after the substantial growth from 7 files to 50 files (108+/108-). This is the "ownCloud Server" → "ownCloud Classic" product-name normalization now applied across the full content tree for the 10.15 branch.

Because a 50-file rename has real risk of catching non-prose targets, I verified every changed hunk specifically for that. Findings:

Clean — only display text / prose / headings changed. No non-prose target was altered:

• antora.yml: only title: changed; the component name: server and version: '10.15' are untouched (correct — name/version are the structural identifiers).
• All xref: targets preserved verbatim (e.g. xref:configuration/server/config_apps_sample_php_parameters.adoc#app-openid-connect-oidc[...], xref:classic_ui:index.adoc[...]) — only the bracketed display text / surrounding prose changed.
• image::/include:: changes are inside the [...] alt-text/title only (e.g. include::example$installation/docker/docker-compose.yml[...], image::.../collabora-online-administration.png[...]) — file/resource targets unchanged.
• URLs untouched (server_release_notes.html#..., the github.com/owncloud/core/.../SettingsManager.php#L195 link, registry.owncloud.com, etc.).
• :page-aliases: (maintenance/upgrade.adoc, ...), :description: attribute values (prose), nav.adoc list label ("ownCloud Classic UI" — display only; the xref: entries below it unchanged), and the README #create-a-new-version-branch-for-owncloud-server anchor target all preserved.
• No code/command/config literal was changed: METRICSAPIKEY, owncloud/server, OCIS_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD, migrate:to-ocis:* occ commands, config.php keys, etc. all intact — only the prose around them was normalized (this also covers the migrating_to_ocis.adoc "OC10"/"ownCloud 10" → "ownCloud Classic" prose tidy-up).

Checks: Build documentation = pass, lint = pass. The Antora build is the authoritative xref/include guard for a 50-file change, and it is green — strong confirmation no reference was broken.

CHANGELOG: n-a (this repo has no changelog).

LGTM — a clean, consistent docs-only normalization. (Not approving/merging here per process; this is a review comment only.)