Thank you for posting your query on Microsoft Q&A platform.
In your scenario you cannot sync multiple forests to single Azure AD tenant. You cannot configure AD connect separately in both forests and sync to single Azure AD tenant as it is not supported.
The only option is to have 2-way trust between both forests and then install AD connect in only one forest.
This will allow AD connect to talk to both forests to pull objects and sync them all to one single tenant.
Many organizations have environments with multiple on-premises Active Directory forests. There are various reasons for having more than one on-premises Active Directory forest. Typical examples are designs with account-resource forests and the result of a merger or acquisition.
When you have multiple forests, all forests must be reachable by a single Azure AD Connect sync server. The server must be joined to a domain. If necessary to reach all forests, you can place the server in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).
The Azure AD Connect installation wizard offers several options to consolidate users who are represented in multiple forests. The goal is that a user is represented only once in Azure AD. There are some common topologies that you can configure in the custom installation path in the installation wizard. On the Uniquely identifying your users page, select the corresponding option that represents your topology. The consolidation is configured only for users. Duplicated groups are not consolidated with the default configuration.
Common topologies are discussed in the sections about separate topologies, full mesh, and the account-resource topology.
The default configuration in Azure AD Connect sync assumes:
Each user has only one enabled account, and the forest where this account is located is used to authenticate the user. This assumption is for password hash sync, pass-through authentication and federation. UserPrincipalName and sourceAnchor/immutableID come from this forest.
Each user has only one mailbox.
The forest that hosts the mailbox for a user has the best data quality for attributes visible in the Exchange Global Address List (GAL). If there's no mailbox for the user, any forest can be used to contribute these attribute values.
If you have a linked mailbox, there's also an account in a different forest used for sign-in.
If your environment does not match these assumptions, the following things happen:
If you have more than one active account or more than one mailbox, the sync engine picks one and ignores the other.
A linked mailbox with no other active account is not exported to Azure AD. The user account is not represented as a member in any group. A linked mailbox in DirSync is always represented as a normal mailbox. This change is intentionally a different behavior to better support multiple-forest scenarios.
Once you have this set up in place then you can configure SSPR. While writing the password back to on-premises, AD connect AD connector account will make the password changes in corresponding forest to which user belongs to.
You can also refer below article to know more about recommended AD connect topologies.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.