Add `/applications/meta` endpoint to enrich application editing / creating experience

[brionmario]

What problem are we solving?

Currently, to determine allowed response types, auth methods, and other relevant behaviors per application type, the frontend relies on the well-known endpoint, which does not provide data scoped to the specific application type. This leads to a disconnect where configuration logic must be hardcoded on the frontend and can't adapt to backend/service evolution or additional app types/flows.

Who are we solving this for?

Primary: Platform Developers

• Goal: Simpler, more maintainable frontend logic for application configuration
• Pain: Hardcoded settings require code changes and lack flexibility. Risk of drift between frontend and backend capabilities.

Secondary: Application Integrators

• Goal: Consistent, predictable API for app configuration
• Pain: Friction due to irrelevant or missing configuration details depending on app type.

Why should we solve this now?

Why now:

• Value to Persona: Developers get a single source of truth for allowed configuration values, directly mapped to each app type, reducing errors and dependencies on app logic knowledge.
• Value to Org: Lower maintenance cost and increased flexibility when introducing new app types or expanding configuration options. Prevents accidental misconfigurations such as those described in Incorrect Configurations allowed in Backend Service Application Type #2458.

Proposed Solution

Introduce an /applications/{id}/meta or /applications/meta endpoint on the backend that:

• Returns the allowed response types, token endpoint auth methods, client types, etc., for each given application (or app type),
• Ensures frontend can dynamically adapt configuration forms based on backend-driven rules without hardcoding,
• Allows future expansion without needing to patch the frontend for every new case.

The existing reliance on the well-known endpoint should be phased out for configuration (not discovery) purposes, moving instead to this application/meta source.

The new meta endpoint should respond to capabilities and limitations appropriate for the app type (e.g., M2M/backend vs. user-interactive apps).

Alternatives

Continue hardcoding config cases in the frontend per application type. This is increasingly fragile and requires manual sync with backend changes.

[Malith-19]

With the introduction of the application Type property currently it has been hard coded in the FE. But with the meta endpoint implementation, we need to clean that one as mentioned in [1].

[1] #4321 (comment)