It depends on how much of the order of development you want to make public to the users of your app, and how much you want to give users the illusion of a sequentially ordered release sequence.
If "2.0.0" is released after 1.3.1, you can write the changelog for 2.0.0 as if 2.0.0 followed 1.3.1 which followed 1.3.0 (even if your internal development order was different). In this case, you can describe the backported change in the 1.3.1 section. This makes it a little bit easier for the readers of the changelog to understand that all changes from 1.3.1 are also included in 2.0.0. It may also give readers of the 2.0.0 changelog a hint that installing 1.3.1 may be useful or sufficient for them, without having to read the 1.3.1 changelog, too.
However, imagine you released 2.0.0 before 1.3.1 (with a change documented under the 2.0.0 section of the changelog), and then start to backport a new change from the 2.1.x line to 2.0.1 and 1.3.1 in parallel, then the changelog of the release 2.0.1 will contain no 1.3.1 section. In this case, both changelogs (of 2.0.1 as well as of 1.3.1) should contain a description bug XYZ fixed within different sections. If you like, you could add also mention in the 2.0.1 section that the same change was backported to 1.3.1, or vice versa.
At the end of the day, the important part is that each release's changelog tells the users correctly what they get with the release - whether a change was introduced during development of 2.0.0, 1.3.1 or 1.3.0 is often less important in retrospective. Still, it will be definitely more convenient when users don't find conflicting information in two different changelogs.
