CAT-FR-AC-02: record the three delivery scope adjustments as ADR 20

[noVaSon]

🚀 Summary

An external review found that three scope adjustments taken during delivery are traceable only in project-internal records and have no entry in the published architecture decision log. Two of the three already carry their technical decision — ADR 9 for the withdrawal of the earlier credential generation, ADR 18 for the graph-backend switching mechanism — but in neither case is the scope dimension recorded: that delivered functionality was consciously reduced, on what grounds, and under what condition it would be restored. The third has no entry at all.

This PR appends ADR 20 to 09_architecture_decisions.adoc, recording all three in one place and one format, each with the same four statements (reduction, rationale, consequences, reversal/reactivation trigger): the deferral of verifiable-credential-based role assertions, the discontinuation of support for the earlier credential generation, and the in-progress substitution of the shipped graph-store default. ADR 20 cross-references ADR 5, ADR 9 and ADR 18 rather than restating their content.

This change is part of the Enhancement of XFSC Federated Catalogue. Details can be found here (permalink):
https://github.com/eclipse-xfsc/docs/blob/f3c6e6b6fbcc87732a1dfe83f060fa58a9a97873/federated-catalogue/src/docs/CAT%20Enhancement/CAT_Enhancement_Specifications%20v1.0.pdf

✅ What's Changed

• Feature implemented / Bug fixed — documentation-only: one new ADR entry, +63 lines, no other file touched
• Documentation updated (if needed)
• Tests added or updated — not applicable (documentation-only change)
• Code formatted and linted — no trailing whitespace, no tabs, one sentence per source line, em-dash characters, AsciiDoc block delimiters balanced

🧪 How to Test

1. Open federated-catalogue/src/docs/architecture/chapters/09_architecture_decisions.adoc and jump to the end of the file.
2. Confirm the new entry is numbered ADR 20 — the chapter header documents that ADR numbers 11–14 are intentionally absent, so 20 is the next free number after ADR 19.
3. Check the three ==== sub-sections each answer the same four questions in the same order, so the three adjustments can be compared at a glance.
4. Confirm ADR 20 does not restate ADR 9 or ADR 18, only points at them.
5. Render the chapter (the docs build) and confirm the new ===/==== headings appear at the right levels in the table of contents.

🔍 Related Issues

Closes #
Related to #

📸 Screenshots (if applicable)

Not a UI change.

📋 Checklist

• I've tested my code locally
• I've added tests if needed
• I've updated documentation if necessary
• My changes follow the project's coding style

---

Reviewer notes

This entry records decisions; it asserts no approval. The review finding asks for a recorded approval of the deferral. An approval is not something this PR can create — ADR 20 states the decision, its reason and its reversal condition. Recording the eco/PMO sign-off itself remains a human action outside this document (the QA workbook).

Two deliberate wording choices, both responses to the review:

• The deferral is called deferred throughout, never "out of scope". The requirement remains part of the specification; it is blocked by the maturity of an external dependency. The coverage note that previously escalated to "not in current FCE scope" has been normalised in the project's own records.
• The graph-store adjustment is written in the present/in-progress tense. The decision is recorded; the artefact repackaging is not yet complete, and the ADR says so explicitly rather than claiming a completed swap.

One known inaccuracy in ADR 9 that ADR 20 does not inherit and does not fix. ADR 9 states that credentials in the earlier format "cannot be uploaded to the catalogue". In the delivered behaviour such a credential is not rejected — it is no longer recognised as a credential and is stored as unverified generic data, so it must be re-issued to regain verified status. ADR 20's consequences paragraph uses the accurate wording. Correcting ADR 9 itself is out of scope here and should be its own change.

[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