App secrets export fails / leaks env values when an env-var override is defined (regression from #35859)

Problem

PR #35860 (issue #35859) added env-var / Kubernetes-secret overrides for app secrets: AppsAPIImpl.getSecrets() now overlays env-var tiers onto the resolved AppSecrets.

The export path (AppsAPIImpl.collectSecretsForExport) builds the export from getSecrets(), so when an env-var override is defined for an app:

• the export fails / produces a corrupt file — a locked (tier-1) env secret carries its value in envVarValue with a null stored value, which breaks the export round-trip; and
• env-sourced values leak into the export file, even though they belong to the target environment, not the exported config.

Expected

Exporting app config must never include env-var overrides. The export should contain only persisted (stored) secrets. A value that is masked by an env override should still export its real stored value.

Fix

collectSecretsForExport reads the persisted secrets blob directly (readStoredSecrets) instead of getSecrets(), so no env value can enter an export. Apps provisioned purely from env (no stored blob — note appKeysByHost() lists env-backed apps) are skipped; the existing empty-result guard still errors when nothing remains to export.

Tests (integration)

• success: stored secret masked by a host env override → export succeeds, round-trip restores the stored value, nothing is fromEnv.
• failure: env-only app (no stored blob) → export throws IllegalArgumentException instead of leaking the env value.

Start with AppsAPIImpl.collectSecretsForExport(), compare its current source with getSecrets() and readStoredSecrets(), and inspect the integration tests described in the issue. Verify that a stored secret masked by a host environment override exports and round-trips its stored value, while an env-only app is skipped and causes the existing empty-result error.