Initialize groundwork for PWA support

[tanmaykapil17]

This PR adds the initial groundwork for Progressive Web App (PWA) support.

What this PR does

• Registers a service worker at the application entry point
• Lays the foundation for future PWA features like offline support and caching

Notes

• This is a minimal, non-breaking change
• No existing functionality is affected

Fixes #9204

Summary by Sourcery

New Features:

• Register a service worker at the application entry point when supported by the browser.

[vercel]

@mtanmaykapil is attempting to deploy a commit to the eventyay Team on Vercel.

A member of the Team first needs to authorize it.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Initial groundwork for PWA support by conditionally registering a service worker when the app boots in browsers that support it.

Sequence diagram for conditional service worker registration on app load

sequenceDiagram
    actor User
    participant BrowserWindow as BrowserWindow
    participant App as EmberApp
    participant Navigator as Navigator
    participant ServiceWorker as ServiceWorkerGlobal

    User->>BrowserWindow: Open application URL
    BrowserWindow->>App: Boot app.js
    App->>Navigator: Check serviceWorker support
    alt serviceWorker supported
        BrowserWindow->>BrowserWindow: Add load event listener
        User->>BrowserWindow: Wait for window load
        BrowserWindow->>Navigator: navigator.serviceWorker.register(/service-worker.js)
        Navigator->>ServiceWorker: Install service worker
        ServiceWorker-->>Navigator: Registration success/failure
    else serviceWorker not supported
        App-->>BrowserWindow: Skip service worker registration
    end

Loading

File-Level Changes

Change	Details	Files
Conditionally register a service worker after the app loads to prepare for PWA features.	Add a runtime check for service worker support via the navigator object Attach a window load event listener to defer service worker registration until after page load Register the /service-worker.js script as the service worker when supported	app/app.js

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• Consider moving the service worker registration into an Ember initializer or similar boot hook instead of at module top-level to better align with the app’s lifecycle and avoid side effects on import.
• It may be helpful to handle and log registration failures (e.g., catching navigator.serviceWorker.register rejections) so diagnosing PWA issues in production is easier.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider moving the service worker registration into an Ember initializer or similar boot hook instead of at module top-level to better align with the app’s lifecycle and avoid side effects on import.
- It may be helpful to handle and log registration failures (e.g., catching `navigator.serviceWorker.register` rejections) so diagnosing PWA issues in production is easier.

## Individual Comments

### Comment 1
<location> `app/app.js:19` </location>
<code_context>
+
+if ('serviceWorker' in navigator) {
+  window.addEventListener('load', () => {
+    navigator.serviceWorker.register('/service-worker.js');
+  });
+}
</code_context>

<issue_to_address>
**question:** Clarify whether service worker registration should occur in all environments or be gated by environment checks.

Unconditional registration will also run in local and test environments, potentially causing confusing caching behavior. Consider guarding this with an environment check (e.g., only in production or behind a config flag) to avoid unintended caching during development.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

question: Clarify whether service worker registration should occur in all environments or be gated by environment checks.

Unconditional registration will also run in local and test environments, potentially causing confusing caching behavior. Consider guarding this with an environment check (e.g., only in production or behind a config flag) to avoid unintended caching during development.