fix(office): select one active suite by default

[amamus]

Description

Aligns the maintained Office example with the current ocis_full suite-selection pattern:

• registers Collabora with oCIS by default and leaves the OnlyOffice entry disabled
• keeps both external Office backends installed so operators can evaluate either suite by reversing the two enabled fields
• adds a Helm release-notes warning when more than one suite is active, explaining the file-locking risk for overlapping formats
• documents the safe switching procedure and the chart-level limitation

The chart intentionally supports multiple collaboration providers. Since each provider's MIME types are discovered at runtime, Helm cannot determine whether enabled suites overlap. The warning therefore preserves advanced disjoint-format deployments while making the interlocking risk explicit instead of rejecting every multi-provider configuration.

Changed Files

• deployments/ocis-office/helmfile.yaml and README.md
• charts/ocis/templates/NOTES.txt
• charts/ocis/values.yaml
• generated charts/ocis/values.schema.json and AsciiDoc values references

Related Issue

• Source of truth: https://github.com/owncloud/ocis/tree/c62b830e932384ba42203b2ed32b10fa42a7f9a5/deployments/examples/ocis_full
• Source interlocking warning: https://github.com/owncloud/ocis/blob/c62b830e932384ba42203b2ed32b10fa42a7f9a5/deployments/examples/ocis_full/.env#L204-L207

Motivation and Context

The example registered Collabora and OnlyOffice simultaneously even though the maintained source profile enables Collabora and leaves OnlyOffice disabled. oCIS does not currently coordinate application locks for the same file across suites, so users can be unable to open or edit a file in one suite until another suite releases its lock.

There is no commit dependency on another alignment PR. PR #965 updates dependency and image versions in earlier sections of the same Helmfile; a clean virtual merge retained both changes and passed focused Helmfile lint.

The exhaustive CI values fixture deliberately keeps both providers enabled to preserve coverage of the chart's supported multi-provider rendering path. It is not a deployment recommendation; the focused release-notes test exercises both the warned multi-suite case and safe one-suite case.

How Has This Been Tested?

• test environment: macOS arm64; Helm 3.16.2; Helmfile 0.169.1; Kustomize 5.8.1; Kubeconform 0.6.7; KubeLinter 0.6.8
• a direct Helm engine render verified that the release-notes warning appears for two active suites, is absent for one active suite, and is absent when apps integration is disabled
• the Office example rendered exactly one collaboration Deployment, Service, and Ingress, all for DemoCollabora; strict Kubernetes 1.31 validation passed for all 101 resources
• the core chart passed all three Helm lint profiles and its configured KubeLinter check; all ten repository deployment examples passed their CI Helmfile lint selection
• strict Kubeconform validation passed on Kubernetes 1.28, 1.29, 1.30, and 1.31: 177 valid resources and zero invalid, errored, or skipped resources per version
• schema and documentation generation was idempotent; chart packaging, schema JSON parsing, and diff checks passed
• a clean virtual merge with PR chore(deps): update office integration charts #965 selected only Collabora, retained the dependency updates, and passed focused Helmfile lint

Screenshots (if appropriate):

Not applicable.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added (not applicable; focused Helm render assertions cover the configuration behavior)
• Acceptance tests added (not applicable; no runtime code changed)
• Documentation generated
• Documentation ticket raised (not applicable)
• Documentation PR created (not applicable)