PO-2671 Update change links on FAE tabs

[GarethLangley1]

Jira link

See PO-2671

Change description

• Added new Change links in the defendant details cards so users can jump directly to the relevant amend sections from the summary UI.
• Wired those links to the correct amend routes with section fragments, so they land on the matching part of the form rather than just the top of the page.
• Added permission checks to keep the existing BU access rules intact, returning /access-denied when the user cannot amend in that business unit.
• Introduced shared section-fragment helpers so the same pattern can be reused cleanly for future sections without duplicating routing logic.
• Added ngAfterViewInit() in the amend form components to scroll to the target section after navigation, because the fragment is only reliable for locating the section once the view exists in the DOM.

Testing done

• Updated the unit tests to cover the new section links, fragments, and scroll behavior, and removed assertions for the old per-tab Change links that were deleted.

Security Vulnerability Assessment

CVE Suppression: Are there any CVEs present in the codebase (either newly introduced or pre-existing) that are being intentionally suppressed or ignored by this commit?

• Yes
• No

Checklist

• commit messages are meaningful and follow good commit message guidelines
• README and other documentation has been updated / added (if needed)
• tests have been updated / new tests has been added (if needed)
• Does this PR introduce a breaking change

[iamfrankiemoran]

[P2] Remove scrolling owned by PO-8911

PO-8911 is the agreed global solution for resetting navigation to the top of the page, so this branch should not introduce a competing component-level scrolling mechanism. Remove this ngAfterViewInit implementation and the related fragment plumbing: DOCUMENT injection, section fragment constants/types, target IDs, [fragment] bindings, helper methods, and scroll tests. Apply the same removal to the payment-terms amend flow while retaining the relocated Change links.

[GarethLangley1]

PO-8911 is the agreed global solution for resetting navigation to the top of the page, so this branch should not introduce a competing component-level scrolling mechanism. Remove this ngAfterViewInit implementation and the related fragment plumbing: DOCUMENT injection, section fragment constants/types, target IDs, [fragment] bindings, helper methods, and scroll tests. Apply the same removal to the payment-terms amend flow while retaining the relocated Change links.

@iamfrankiemoran the purpose of this work, is that when a user click on a 'section' change link, we are looking to scroll them to that particular section of the proceeding page/form e.g. user clicks on 'Employer details' under the 'Parent or guardian tab' they are then automatically scrolled to the 'Employer Details' part of the form. So in these conditions, we would want to avoid scrolling to the top of the page.

[iamfrankiemoran]

PO-8911 is the agreed global solution for resetting navigation to the top of the page, so this branch should not introduce a competing component-level scrolling mechanism. Remove this ngAfterViewInit implementation and the related fragment plumbing: DOCUMENT injection, section fragment constants/types, target IDs, [fragment] bindings, helper methods, and scroll tests. Apply the same removal to the payment-terms amend flow while retaining the relocated Change links.

@iamfrankiemoran the purpose of this work, is that when a user click on a 'section' change link, we are looking to scroll them to that particular section of the proceeding page/form e.g. user clicks on 'Employer details' under the 'Parent or guardian tab' they are then automatically scrolled to the 'Employer Details' part of the form. So in these conditions, we would want to avoid scrolling to the top of the page.

Following discussion with the PO-8911 work, the intended approach is to configure Angular router scrolling centrally:

withInMemoryScrolling({
  anchorScrolling: 'enabled',
  scrollPositionRestoration: 'top',
})

This means ordinary navigation will open at the top, while Change links containing fragments will navigate to the corresponding form section.
Please retain the fragment bindings and matching destination IDs, but remove the component-level scrolling implementation from this branch, including:

• AfterViewInit
• DOCUMENT injection
• getElementById()/scrollIntoView() calls
• tests specifically covering those manual calls
  The fragment values should also be moved into shared constants so the source links and destination forms cannot drift apart. Tests in this branch should verify that links produce the correct fragments and that matching target IDs are rendered.

[GarethLangley1]

PO-8911 is the agreed global solution for resetting navigation to the top of the page, so this branch should not introduce a competing component-level scrolling mechanism. Remove this ngAfterViewInit implementation and the related fragment plumbing: DOCUMENT injection, section fragment constants/types, target IDs, [fragment] bindings, helper methods, and scroll tests. Apply the same removal to the payment-terms amend flow while retaining the relocated Change links.

@iamfrankiemoran the purpose of this work, is that when a user click on a 'section' change link, we are looking to scroll them to that particular section of the proceeding page/form e.g. user clicks on 'Employer details' under the 'Parent or guardian tab' they are then automatically scrolled to the 'Employer Details' part of the form. So in these conditions, we would want to avoid scrolling to the top of the page.

Following discussion with the PO-8911 work, the intended approach is to configure Angular router scrolling centrally:

withInMemoryScrolling({
  anchorScrolling: 'enabled',
  scrollPositionRestoration: 'top',
})

This means ordinary navigation will open at the top, while Change links containing fragments will navigate to the corresponding form section. Please retain the fragment bindings and matching destination IDs, but remove the component-level scrolling implementation from this branch, including:

• AfterViewInit
• DOCUMENT injection
• getElementById()/scrollIntoView() calls
• tests specifically covering those manual calls
  The fragment values should also be moved into shared constants so the source links and destination forms cannot drift apart. Tests in this branch should verify that links produce the correct fragments and that matching target IDs are rendered.

@iamfrankiemoran this has now been implemented 👍

[iamfrankiemoran]

LGTM ✅

[TimDanielsCQI]

LGTM

[Ju-Morgan]

ALGTM