[tests-only][full-ci] Test: run Core-API-8 test suite on k8s

[anon-pradip]

Description

This PR enables Unicode text preview support for the thumbnails service in Kubernetes, ensures consistent thumbnail generation between test builds and production images, and fixes a flaky TUS upload test.

Problem

1. K8s deployments: Thumbnails service couldn't render Unicode characters (e.g., Devanagari script) due to missing fonts
2. Inconsistent test builds: Test builds used standard Go image/jpeg encoder while production Docker images (built with ENABLE_VIPS=true) use libvips encoder, causing different JPEG output and test failures
3. Flaky TUS test: coreApiWebdavUploadTUS/lowLevelUpload.feature: send last chunk twice was failing in Drone CI K8s with 409 but passing locally with 404

Changes

1. K8s Font Support

• Added ConfigMaps for NotoSans font and font configuration
• Mounted fonts into thumbnails deployment for Unicode text rendering

2. Consistent Test Builds

• Added ENABLE_VIPS=true to test builds to match production images (which already have VIPS enabled)
• Updated 5 preview fixtures to match VIPS output (JPEG with EXIF metadata):
  • unicode-fixture.png: 620 → 739 bytes
  • fit.png: 713 → 885 bytes
  • fill.png: 874 → 1029 bytes
  • resize.png: 829 → 984 bytes
  • thumbnail.png: 874 → 1029 bytes

3. TUS Upload Test Fix

• Updated test expectation from 404 to 404 or 409 for "send last chunk twice" scenario

Passing CIs:

• with K8: https://drone.owncloud.com/owncloud/ocis/49370/51/8
• without K8: https://drone.owncloud.com/owncloud/ocis/49371/51

Related Issue

• Part of: [QA] Fix failing tests on suites running on k8s #11658
• TUS upload: Inconsistent HTTP status codes (404 vs 409) when re-uploading to completed session in K8s #11854 (comment)

Motivation and Context

How Has This Been Tested?

• test environment:
• test case 1:
• test case 2:
• ...

Screenshots (if appropriate):

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
• Acceptance tests added
• Documentation ticket raised:

[nirajacharya2]

why do we get 409 now?

[anon-pradip]

Here is the confirmation issue: #11854 (comment)

[saw-jan]

we get 409 when there's offset mismatch which will be the case when the upload session is found (due to race condition). So expecting 404 or 409 is ok IMO.

For future refs:
https://github.com/owncloud/reva/blob/38a73a6cb88ef46b12a3de9f912284d697588b42/pkg/rhttp/datatx/manager/tus/tus.go#L181-L188
⬇️
https://github.com/tus/tusd/blob/c3cef4460b0cb4cf887724d722000e018bb435b2/pkg/handler/unrouted_handler.go#L788-L791 (Status 409)

OR
https://github.com/tus/tusd/blob/c3cef4460b0cb4cf887724d722000e018bb435b2/pkg/handler/unrouted_handler.go#L770-L774 (Status 404)
⬇️
https://github.com/owncloud/reva/blob/38a73a6cb88ef46b12a3de9f912284d697588b42/pkg/storage/utils/decomposedfs/upload.go#L362-L370
⬇️
https://github.com/owncloud/reva/blob/38a73a6cb88ef46b12a3de9f912284d697588b42/pkg/storage/utils/decomposedfs/upload/store.go#L136-L147

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud