Update ConsentInfo API proposal to reflect new functional scope agreed by TSC

[albertoramosmonagas]

What type of PR is this?

• documentation

What this PR does / why we need it:

This PR refines the scope and disclaimer of the Consent Info API to explicitly clarify that:

• The API does not delegate consent or privacy management to third parties.
• The Operator remains fully responsible for the consent process, both in frontend and backend flows.
• The frontend flow (Authorization Code Grant) allows the developer to obtain consent directly from the user through browser interaction.
• The backend flow (CIBA) delegates consent capture to the Operator, who uses its own channels (push notification, SMS, etc.).

This update is critical to avoid misinterpretation of the Consent Info API scope by API consumers, and ensures alignment with Telco privacy and legal expectations.

Which issue(s) this PR fixes:

Fixes #246

Special notes for reviewers:

• No changes to the API structure or flows.
• Clarification is editorial/documentational only, based on previous TSC discussions.
• Please validate if the current phrasing avoids ambiguity in terms of responsibility for consent capture.

Changelog input

 release-note
Updated Consent Info API documentation to clarify Operator responsibility in consent management, across frontend and backend flows.

Additional documentation

docs
Clarified disclaimer and scope description in Consent Info API summary to reflect actual operator-developer roles in both Authorization Code and CIBA flows.

[caubut-charter]

LGTM

[jgarciahospital]

LGTM

[jgarciahospital]

@AxelNennker can you please check this before moving on with new proposals? This is just a formality to ensure the the description of current Consent Info API is aligned with current API.