Partner self declare

User Story
As a ministry or student user, I need to update the workflow processes to accommodate the use of the Supporting User form for partner/common-law self-declaration. This is important to help students complete their applications accurately and ensure proper data collection.

## Acceptance Criteria
### Baseline Information

- [ ] Applies to 2026–27 program year and onward.
- [ ] Ensure pre 2026-2027 still functions using the current path
- [ ] Change effects both FT and PT

### Modify Application

- [ ] Replace the current partner/common-law questions with a function similar to the dependants section that allows entry of information free form.

- [ ] Only one entry will be allowed so it does not need to behave as an array that allows additional lines of info.

- [ ] Student will default have one box for adding a partner/common-law if they indicate they have one previously in the application

- [ ] Use a validation to ensure partner’s full name does not match the student’s full name (soft warning).

- [ ] Wire frame, content is exact and can me mimicked exactly

- [ ] Remove the exception for partner current year income as an available question in the form (it will be replaced by an appeal in a coming ticket.) (If ticket number 5616 is completed first this AC is not required as the question will already be removed)
- [ ] Remove all questions that were hidden under answering "no" to the BC services card question as they will not longer be used for student self declaring partner information.
- [ ] Ensure if the answer to the BC Services card question = no then there should be no ability for the actual partner to go to the supporting user portal and submit a form

## Technical Acceptance Criteria

DATA

- [ ] Stop relying on the student partner data from the application and start to utilize the data from the student self declare utilizing the supporting user form.

### Workflow

- [ ] Assessment Gateway: (pulled from previous parent effort validate assumption is true that this is still needed for partner)

- [ ] Worker Changes
- [ ] Use existing worker: create-identifiable-supporting-user.
- [ ] Do note remove existing worker as it will continue to be used for program years 25-26 and earlier. (backwards compatibility)
- [ ] Handles partner creation
- [ ] Idempotent using full name + relationship type.

- [ ] Data Loading
- [ ] Reuse load-assessment-consolidated-data.
- [ ] Add mapping for studentDataPartner.

- [ ] Remove inline partner data dependencies.
- [ ] Use only data from Supporting User dynamic column.

- [ ] Supporting user creation for partners should start to use the create-identifiable-supporting-users worker instead of `create-supporting-users`.
- [ ] Gateway v3 introduced or utilize the focus of a different "new question" to avoid v3 creation

## Supporting user form update and camunda (Ticket 2)
### Acceptance Criteria
#### Form changes

- [ ] These changes are for the new partner self declare path and need to be applied for both PT and FT
- [ ] Add a banner to the top when the student is reporting on behalf of their partner
Content:

> You are submitting this declaration on behalf of your partner. Please complete the following financial information questions with your partner's information.

- [ ] Remove all personal information fields and replace with:
Given names
Free entry field

Last name
Free entry field

- [ ] Contact information section remains as is for both student and partner reporting scenarios

Self declare mock up

Assessment

- [ ] Ensure the new data element for the partner self declare path is used will function in the assessment and consolidated data
### Ticket 3
** User Story**

Follow-up effort to update the tracker card when a student needs to self declare their partner information. This is set to match the parent self declare path that already exists.

Acceptance Criteria
Update Partner/Common-law Tracker Cards
Student Declare

- [ ] If a student is self declaring for their partner, update the tracker card to show as a “warning” card with a button.

- [ ] Tracker card includes one “Student Declare” button for the student to access the form to enter the partner/common-law information.

The “Student Declare” button will display as the full name of the partner/common-law to be declared, as provided in the application.

Change when the Partner/Common-law information complete green tracker card shows:

Only display it when all student and partner/common-law declared information is provided.

Partner/Common-law information required for [partner/common-law full name]

You have indicated that [partner/common-law full name] is unable to complete their declaration. Please complete the following declaration on their behalf.
Click on the button below to complete the declaration.

Declare

Partner/Common-law Declare

Waiting for additional information from [partner/common-law full name]

We are waiting for supporting information from [partner/common-law full name].
Please check your email from StudentAidBC for further instructions.
The email includes important details and a secure link that your partner/common-law will need in order to provide their information for your application.

## Ministry view (Ticket 4)

### Application History Menu
As a ministry user i want to see the partner as its own isolated item similar to the parent behaviour for student and partner declared submissions

- [ ] Applies to 2026–27 applications only.

- [ ] Update menu labels to show partner full name in the application side menu instead of generic “Partner” for all states:

- Active
- Change Request
- History

- [ ] Truncate partner name if it spills over in the side menu.

- [ ] When partner name is not present, default to “Partner”.

- [ ] Add a new subtitle for the partner declaration in the application history section:

- Student Declared
- Partner Declared

- [ ] Add student header banner to the supporting user application form view.

- [ ] Add partner full name below student header information on the page:

Title: Partner information: [partner full name]

- [ ] Ensure data provided by the student is displayed in the supporting user form.

Technical Notes (from parent modified to partner remove if inaccurate

Use existing Supporting User form rendering logic for partner.
Ensure data binding for partner name and declaration type (student vs partner).
Apply truncation logic consistent with parent implementation.
Reuse header banner component from parent flow.
No changes to backend API if partner data already exposed via supportingUsers[].

Acceptance Tests

Partner name appears in side menu for active, change request, and history states.
Name truncates correctly when too long.
Defaults to “Partner” when name missing.
Application history shows Student Declared and Partner Declared subtitles.
Supporting User form view displays:

Student header banner.
Partner full name in title.
Data provided by student visible in form.

### Ticket 5
User Story
As a student, I need to receive a notification so that I can advise my parent(s) to submit supporting information for my application.

** Acceptance Criteria **

- [ ] New email templates for partner declaration 26/27 onward
- [ ] Email will be sent once
- [ ] Templates will need partner full name (from student app) and application number as additional variables
- [ ] Two new templates will be used, one for partner declare, and one for student declare of partner
- [ ] Partner supporting user email to remain the same with existing template
- [ ] Student can declare template (To be added)
- [ ] Partner can declare template (To be added)

## Additional context

- No need to change the supporting user login path for partner as there will still only be one partner and they can continue to find the application using the

## Technical AC
- Review existing parent notifications which can be greatly simplified by removing duplicate methods/interfaces