version upgrades don't automatically load new `js`/`css` files

[sidnym-ladrut]

When a new version of %fund goes out, users will almost always encounter issues loading the app front-end because their browser has cached versions of the old front-end. This was supposed to be fixed by #76, but the ?v=X.Y.Z strategy didn't work (at least for some users on the Brave browser). A more complete and thoroughly-tested solution is required.

---

For the sake of clarity, the following is the expected control flow when a user's browser requests an asset like test.js:

1. If the asset has no version label like test.js, redirect to test.js?v=1.2.3 via a 303.
2. If the asset has a bad version label like test.js?v=1.2.2, then 404.
3. If the asset has a good version label like test.js?v=1.2.3, then 200 with the content.

It's important to note that only the 200 result should be cached, i.e. test.js?v=1.2.3; according to sitepoint, 303 redirect locations will not be cached, but the content pointed to will be cached. Also, 303 seems to be the best redirect choice based on the decision chart provided here.

[sidnym-ladrut]

When testing the expected behavior locally, I had the following results:

test case	expected	brave	firefox
edit js file only	loads cached	loads latest	loads cached
edit js file and desk version	loads latest	loads latest	loads latest

My Brave settings seems to have aggressive cache-clearing GET headers across the board (i.e. Cache-Control: no-cache and pragma: no-cache), which is why it loads even when it shouldn't. Regardless, I was unable to replicate this bug on my end, and all the remote and cached %fund projects I tested over the clearweb worked in Brave after the update (this could come down to my settings).

I'll leave this issue open for now and we'll keep an eye on it; hopefully, the problem we saw immediately after the v0.2.2 upgrade was a fluke!