fix: flaky wopi test due to app registry ordering

[mklos-kw]

Fixes potential cause of flakiness in wopi.feature, failed 10 pipelines in ocis/master last 200 commits alone

Likely root cause: Test assumes default app = FakeOffice when no app_name; server uses first provider from registry (order = priority then registration, or snapshot timing); that first provider is not guaranteed to be FakeOffice.

• Tests: Four open-with-web scenarios (wopi.feature 348–372, 396, 418, 449) send POST to /app/open-with-web?... with no app_name in the second example row; FeatureContext::theJsonDataOfTheResponseShouldMatch() asserts uri matches a pattern with app=FakeOffice.
• Missing in tests: No check that FakeOffice is in the provider list or first; no call to /app/list before asserting; the second row does not send app_name=FakeOffice even though the assertion requires it.
• Missing in server: When app_name is empty, appprovider.go 394–411 sets appName = apps.Providers[0].Name; the handler never uses default_app or GetDefaultProviderForMimeType (registry config in ocis/tests/config/drone/app-registry.yaml has default_app: FakeOffice but that is not honored).
• Provider list source: appregistry.go 103–112 returns Providers: p from FindProviders(ctx, MimeType); order = registry order (static: static.go 153–178 heap/registration order; micro: micro/manager.go 219–236 sortByPriority(lst) then registration order into m.mimeTypes).
• Most of the time: Micro registry sortByPriority (manager.go 225) keeps stable order when all have default priority "0"; if CI runs wopi-fakeoffice → wopi-collabora → wopi-onlyoffice sequentially, FakeOffice registers first and is Providers[0], so the test passes.
• When flakiness strikes: Either (a) Providers[0] is Collabora (registration order or priority differs), so response uri contains app=Collabora and the schema pattern app=FakeOffice fails; or (b) updateProvidersFromMicroRegistry() snapshot (manager.go 63, ticker 69–86 every 30s) was taken before FakeOffice registered, so FakeOffice is missing from the list and Providers[0] is again another app (e.g. Collabora).
• Evidence in fails: failed steps logs show "app=Collabora" in uri vs expected app=FakeOffice; failed step is localApiTests-wopi; scenario e.g. open file with .odt extension (open-with-web) at wopi.feature 348 (second example row).

Possible fixes

1. Change open-with-web fallback in reva/internal/http/services/appprovider/appprovider.go to resolve default app via GetDefaultProviderForMimeType (or equivalent deterministic policy) instead of apps.Providers[0]. default_app for that MIME type (in oCIS CI that’s default_app: FakeOffice in tests/config/drone/app-registry.yaml), making the chosen app deterministic and matching what the WOPI tests assert.
2. Keep current server behavior but enforce deterministic registry order in CI by assigning explicit app-provider priorities (FakeOffice highest) so sortByPriority always yields stable first provider. reva has priority config, however oCIS does not expose it.
3. Keep server behavior unchanged and split acceptance tests into explicit-app vs no-app cases, where no-app assertions validate selected app from /app/list (or any valid provider) rather than hardcoded app=FakeOffice.

[kobergj]

small question. Approach itself looks good 👍

[kobergj]

Why do we still need this logic here? Shouldn't GetDefaultAppProviderForMimeType already resolve that for us?

[mklos-kw]

apps.Providers[0] would be a last resort fallback - reva support priority config. Can be removed if can be a source of further errors.

[jvillafanez]

I think we'd need to do a SetDefaultAppProviderForMimeType call somewhere. We can't set a default from the AddAppProvider call.
This needs to be setup by the admin, likely via environment variables (not done at the moment). And we need to assume that the admin won't do it.

[mklos-kw]

ocis test FakeOffice config: src

Added stable sorting here in handler and in registry that should be enough to fix test issue.
Good point, for no-config (quickstart) case there could be some auto register for default app - I'd take into a separate issue.

[jvillafanez]

From a user's perspective, I don't think the server should change too much: the user will want to open the files with the app he chooses. The only reason for the user to open the file with a random app would be because he could choose the app in the first place.

Now, assuming the user doesn't provide an app name for whatever reason, I agree the result should be as predictable as possible. In general, the changes in this PR looks good to me.
Taking into account that we expect just a few app providers (not more than 5), we can consider the following behavior based on these changes:

1. Choose the default app for the mimetype if possible.
2. If not possible, sort the apps available (we expect less that 5 apps, so sorting should be fast). Sorting by app name seems a good idea.
3. Choose the first one of the sorted list.

This way, the results are more predictable.

With those changes, we have 2 options for the tests:

• Force the tests to set the default app. This is the test's responsibility, and the actual production instance might have different values.
• Adjust the app names for the tests to ensure the app name we want is always the first option.