feat(web/lifecycleService): correct startupKind

[samdenty]

This PR fixes #206345 & #206296.

Before the startupKind was only implemented for electron, but we can also do it on web (only found out cause chatgpt suggested). This makes the editor restoration logic better (and i'm sure other parts that use startupKind too)

---

Submitted with StackBlitz.

[bpasero]

@samdenty any thoughts on https://web.dev/articles/navigation-and-resource-timing#acquiring_timings_in_application_code. I wonder about the actual perf impact of calling performance.getEntriesByType('navigation'). In my testing on macOS, I could not find this call to take long, but I wanted to point out the blog post that suggests a observer pattern.

[samdenty]

iterating over a large number of entries, or even repeatedly polling the performance buffer to find new entries

I think since this we're calling performance.getEntriesByType('navigation') there should only ever be one event, so browsers shouldn't have a hard time resolving that. If it was a different type, then yeah that could be an issue.

The observer pattern seems to be for when you want to subscribe to the latest events, instead of polling the API

[bpasero]

👍 , I think this can go in, I pushed some slight 👄 changes.

One thing that will be received as some kind of regression potentially is that in web, we no longer just restore the previous view you had opened (you removed the isWeb check). But on the other hand, that is consistent with the behaviour on desktop and as such actually the intended behaviour. I hope this will not backfire though...

[bpasero]

Interesting: 5727c82