feat: expose shouldSkipOnBackForwardUI on NavigationEntry

[MarshallOfSound]

Description of Change

Chromium's history manipulation intervention marks a history entry "skippable" when the page created it and then navigated away without a user gesture (client-side redirectors, login bounces, pushState back-traps). The native goBack()/goForward()/canGoBack() honor the flag and skip such entries; goToIndex() deliberately does not. The flag lives internally on content::NavigationEntryImpl, and Electron's NavigationEntry structures don't expose it.

This PR exposes the flag as a read-only boolean property — shouldSkipOnBackForwardUI — on the NavigationEntry structures returned by navigationHistory.getEntryAtIndex() and navigationHistory.getAllEntries(). The property name mirrors the internal Chromium name and is open to API-WG bikeshedding.

Motivating use case: an embedder that needs deterministic, policy-gated history navigation peeks the target entry (navigationHistory.getEntryAtIndex(active ± 1)), validates it against a security policy, then commits with goToIndex() so the gated URL is exactly what commits. Without the skippable flag, that pattern can't honor the intervention — on a stack [A, R, B] where R auto-redirects forward, "back" from B lands on R and bounces, while native goBack() would have skipped to A. Exposing the flag lets the embedder walk the peek past skippable entries using Chromium's own ground truth instead of re-implementing the heuristic.

Implementation:

• A minimal Chromium patch (feat_expose_shouldskiponbackforwardui_on_content_navigationentry.patch) adds a public const accessor ShouldSkipOnBackForwardUI() to content::NavigationEntry, implemented by NavigationEntryImpl which already owns the flag. This is a reasonable candidate to upstream to Chromium proper, as noted in the patch header.
• The Electron-side change is a single dict.Set() in the content::NavigationEntry* → V8 converter, which backs all NavigationEntry-structure-producing APIs.
• The property is documented as optional so the TypeScript change stays additive (NavigationEntry is also the input type of navigationHistory.restore(), where the property is ignored).
• Specs build a real [A, R, B] stack against the spec HTTP server where R navigates away via renderer-initiated location.assign with no user gesture, and assert the flag is [false, true, false] plus the existing behavior contrast: goBack() from B commits A while getEntryAtIndex(active - 1) still returns R.

Checklist

• I have built and tested this change
• I have filled out the PR description
• I have reviewed and verified the changes
• tests are changed or added
• relevant API documentation, tutorials, and examples are updated and follow the documentation style guide
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Added shouldSkipOnBackForwardUI to the NavigationEntry structure, exposing whether Chromium's history manipulation intervention will skip the entry on back/forward navigations.

[jkleinsc]

API LGTM

[itsananderson]

Small suggestion for the explanation of the "optional" property, but otherwise API LGTM

[itsananderson]

I'm wondering if this wording will cause confusion. Here's a suggestion that's a little more verbose, but hopefully less likely to cause confusion?

Suggested change

	with `navigationHistory.goToIndex(index)`. Always present on entries returned by Electron; it is
	ignored when passed to `navigationHistory.restore()`.
	with `navigationHistory.goToIndex(index)`. This property is always defined as `true`/`false`
	on entries returned by Electron; it is marked as optional because it is ignored when passed
	to `navigationHistory.restore()`.