refactor(Tag Tracking+): Improve loop edge cases, misc cleanup

[marcustyphoon]

Description

Note: every change in this PR is included in/superseded by #2375. It only makes sense to review this if not imminently merging that one (which: extremely reasonable position)... or, in theory, to reduce the diff of that PR, but actually this implementation differs more from it than I hoped, so it doesn't really do that.

This:

• Rewrites the Tag Tracking+ refresh loop so that it can actually be immediately stopped instead of finishing its loop unconditionally, firing up to 100 extra API requests over time if the feature is disabled. Now: because we use onStorageChanged in Tag Tracking+, this doesn't happen on preference changes, so it only happens on manual feature disable; yes this is entirely pointless. There might be edge cases where this rewrite also improves loop timing consistency, as it no longer has a setInterval call that's up to 50 minutes in duration, but I can't think of a situation where the old code would actually misbehave. Putting the device to sleep? Nah, should be fine.
• Stops doing anything after adding the sidebar if there are 0 tracked tags. Resolves Tag Tracking+: Infinite loop if user tracks zero tags #2338.
• Renames storageKey to timestampsStorageKey (and types the storage object).

Screenshots

n/a

Testing steps

• Optionally, un-revert the test commit.
• Enable Tag Tracking+ with browser dev tools open. Disable it during the initial load waterfall and confirm that API fetches immediately stop.
• Enable Tag Tracking+ with browser dev tools open. Disable it after the initial load waterfall during regular background refreshing and confirm that API fetches immediately stop.
• Smoke test Tag Tracking+.