Navigator: fix isInitial logic

[ciampo]

What?

Discovered while working on #65523

Set the isInitial flag to false in the internal Navigator reducer only when effectively navigating to a new screen.

Why?

Previously, the isInitial flag was set to false on every navigation, even the ones that were not leading to effectively navigating to a new screen. This was causing unwanted side effects, like the one flagged in #65523

How?

The isInitial flag is set to false only when navigating to a new location.

Testing Instructions

In Storybook:

• Apply the following diff

diff --git a/packages/components/src/navigator/stories/index.story.tsx b/packages/components/src/navigator/stories/index.story.tsx
index 30b9c71a36..8d4881a563 100644
--- a/packages/components/src/navigator/stories/index.story.tsx
+++ b/packages/components/src/navigator/stories/index.story.tsx
@@ -64,6 +64,10 @@ export const Default: StoryObj< typeof NavigatorProvider > = {
 					<h2>This is the home screen.</h2>
 
 					<VStack alignment="left">
+						<NavigatorButton variant="primary" path="/">
+							Go to home screen.
+						</NavigatorButton>
+
 						<NavigatorButton variant="primary" path="/child">
 							Go to child screen.
 						</NavigatorButton>

• Load the default Storybook example for Navigator
• Click on the "Go to home screen" button
• Make sure the screen doesn't animate

In the editor:

• Open site editor
• Open the global styles sidebar
• Make sure the initial screen doesn't animate

Screenshots or screencast

Before (trunk)	After (this PR)
Kapture.2024-09-20.at.14.24.56.mp4	Kapture.2024-09-20.at.14.26.11.mp4

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <[email protected]>
Co-authored-by: tyxla <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[tyxla]

Makes sense, thanks for the fix 🚀

[tyxla]

The failing tests seem unrelated FWIW.

[ciampo]

Yeah, the e2e test failures are about block bindings and can be seen across many other PRs, so they they're not related. All e2e and unit tests related to these changes are passing, so I'm going to merge anyway.

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/6.7 branch. Please resolve the conflict manually and create a PR to the wp/6.7 branch.

PRs to wp/6.7 are similar to PRs to trunk, but you should base your PR on the wp/6.7 branch instead of trunk.

# Checkout the wp/6.7 branch instead of trunk.
git checkout wp/6.7
# Create a new branch for your PR.
git checkout -b my-branch
# Cherry-pick the commit.
git cherry-pick efd622d95ebd6721c844949d57c559de67b17101
# Check which files have conflicts.
git status
# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue
# Push the branch to the repository
git push origin my-branch
# Create a PR and set the base to the wp/6.7 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[ciampo]

The backport has a conflict because of #65564 not being backported yet. Let's wait for that PR to be backported first

[github-actions]

I just cherry-picked this PR to the wp/6.7 branch to get it included in the next release: bc3af46