Can we make to avoid to invoke ServiceWorker _by default_ for if user code call `event.addRoutes(rules)` in `install` event handler?

Motivation

event.addRoutes(rules) was introduced by #1701 whose motivation is explained in https://github.com/WICG/service-worker-static-routing-api to reduce the overhead to intercept by ServiceWorker.

According to the motivation, I seem our ideal status resolved by this API is ServiceWorker works as opt-in mode if a user code calls event.addRoutes().

I think almost combinations of RouterRule would be nice to work like opt-in semantics. However, there are some cases that are not intuitive combinations.

For example, the explainer illustrates Bypassing ServiceWorker for particular resources case. This case say that ServiceWorker to behave as just as opt-out for some network request path

// This example is cited from the explainer.
// I think this shows opt-out behavior semantics.
// -----

// Go straight to the network and bypass invoking "fetch" handlers for URLs that start
// with '/videos/' and '/images/'.
addEventListener('install', (event) => {
  event.addRoutes([{
    condition: {
      urlPattern: new URLPattern({pathname: "/images/*"})
    },
    source: "network"
  },
  {
    condition: {
      urlPattern: new URLPattern({pathname: "/videos/*"})
    },
    source: "network"
  }]);
});

On the other hands, if RouterRule.source is "fetch-event” or cache, ServiceWorker would work like as opt-in for registered conditions by the spec.

// By the current spec, this indicates ServiceWorker should wake up
// and intercept for URLs with `/assets/`. I seem this shows opt-in behavior semantics.
addEventListener('install', (event) => {
  event.addRoutes([{
    condition: {
      urlPattern: new URLPattern({pathname: "/assets/*"})
    },
    source: "cache"
  },

If I don't misunderstand the spec, I think this API semantics inconsistency may confuse a developer.

Idea

I also propose a rough idea to resolve this behavior inconsistencies.

1. Introduce a new internal mode that ServiceWorker behaves like a pass through mode.
   1. Under this mode, ServiceWorker only works with registered conditions.
   2. For other (non-registered) conditions, ServiceWorker does not startup.
2. Make ServiceWorker to pass through mode if user calls event.addRoutes() once in the install event handler.
   1. Luckily, event.addRoutes() is a newly introduced API. That method does not exist on old UAs. If user code does not call event.addRoutes(), ServiceWorker can work as a traditional style that intercept for all network requests implicitly.
   2. For UAs that had been shipped event.addRoutes() (Google Chrome), they can just ignores some patterns of conditions to keep a backword compatibility.

Start with the ServiceWorker static routing API motivation and the on-fetch-request algorithm linked in the issue. Compare the proposed pass-through mode with the existing network, fetch-event, and cache sources, including the install handler's event.addRoutes() behavior. Done means the semantics are specified consistently while preserving compatibility for user agents without the API.