fix(orientation): wrong result with address on 2 postcodes

What does this MR do and why?

In orientation, when searching around an address which exists with 2 different postcode, the result of structure is not relevant. Example with addresses: 45 Rue Félix Brun Lyon 7ème Arrondissement / 45 Rue Félix Brun Vénissieux. With data from example, the actual behaviour is wrong and when we try to get structure around the address at Lyon 7 we will get structure around address at Vénissieux.

This MR is adding the postcode in the function which retrieve structures.

No Squash is needed as only one commit has been done.

| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Screenshots or screen recordings

Screenshots before and after the fix. before:

after:

How to set up and validate locally (or on alpha)

• Pull the branch
• Launch frontend and backend
• Go to the Orientation screen and follow the forms.
• When asked, use "45 Rue Félix Brun Lyon 7ème Arrondissement" as address
• Ensure that the displayed structure in the lists are the good one (refer to the screenshot).

MR acceptance checklist

To be completed by the chosen reviewer.

Quality

• Confirmed

1. For the code that this change impacts, I believe that the automated tests validate functionality that is highly important to users. If the existing automated tests do not cover this functionality, I have added the necessary additional tests or I have added an issue to describe the automation testing gap and linked it to this MR.
2. I have made sure that the sonar quality coverage is up to standards.
3. I have considered the impact of this change on the front-end, back-end, and database portions of the system where appropriate and applied.
4. I have tested this MR in all supported browsers or determined that this testing is not needed.
5. I have confirmed that this change is backwards compatible across updates (migrate up needs a migrate down), or I have decided that this does not apply.

Performance, reliability and availability

• Confirmed

1. I am confident that this MR does not harm performance, or I have asked a reviewer to help assess the performance impact.
2. I have considered the scalability risk based on future predicted growth.

Documentation

• Confirmed

1. I have prepared a squash commit to feed the changelog linked to the current milestone.
2. I have added/updated documentation (also updated if the changes feature a deprecation) or I have decided that documentation changes are not needed for this MR.

Security

• Confirmed

1. I have confirmed that if this MR does not contains any sensitive informations hidden in the changes.

Deployment

• Confirmed

1. When featured on a self-data project release, i have made sure my app version in the manifest and package.json is incremented and any relative changes to the permissions are clearly written and transmitted to Cozy.