Hello,

I'm working on fixing some issues which I encounter while trying to bump Flask and Werkzeug to the current recent version >= 3.0.0 in Debian. While looking at the various problems I discovered that the test suite of beets if failing with bumped versions of (Flask and) Werkzeug to >=2.3.x (no just with 3.0.0!).

### Problem

Running the test within an environment there a recent Werkzeug version (>= 2.3.8) is installed will trigger a failing test of `WebPluginTest.test_get_single_item_by_path` in [test/plugins/test_web.py L142](https://github.com/beetbox/beets/blob/master/test/plugins/test_web.py#L142).
Note that Debian is still using the latest released version of 1.6.0, where the `test/` folder isn't refactored yet.

```sh
...
102s test/test_zero.py ................. [100%]
102s
102s =================================== FAILURES ===================================
102s __________________ WebPluginTest.test_get_single_item_by_path __________________
102s
102s self =
102s
102s def test_get_single_item_by_path(self):
102s data_path = os.path.join(_common.RSRC, b'full.mp3')
102s self.lib.add(Item.from_path(data_path))
102s response = self.client.get('/item/path/' + data_path.decode('utf-8'))
102s > res_json = json.loads(response.data.decode('utf-8'))
102s
102s test/test_web.py:140:
102s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
102s /usr/lib/python3.11/json/__init__.py:346: in loads
102s return _default_decoder.decode(s)
102s /usr/lib/python3.11/json/decoder.py:337: in decode
102s obj, end = self.raw_decode(s, idx=_w(s, 0).end())
102s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
102s
102s self =
102s s = '\n\n404 Not Found\n

Not Found

\n

The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.

\n'
102s idx = 0
102s
102s def raw_decode(self, s, idx=0):
102s """Decode a JSON document from ``s`` (a ``str`` beginning with
102s a JSON document) and return a 2-tuple of the Python
102s representation and the index in ``s`` where the document ended.
102s
102s This can be used to decode a JSON document from a string that may
102s have extraneous data at the end.
102s
102s """
102s try:
102s obj, end = self.scan_once(s, idx)
102s except StopIteration as err:
102s > raise JSONDecodeError("Expecting value", s, err.value) from None
102s E json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
102s
102s /usr/lib/python3.11/json/decoder.py:355: JSONDecodeError
...
```

The root for the issue is that the data of `response` isn't providing the data that is expected. A successful test is getting these data items:

```
b'{"acoustid_fingerprint":"","acoustid_id":"","added":1704284421.6018217,"album":"the album","album_id":null,"albumartist":"the album artist","albumartist_credit":"","albumartist_sort":"","albumdisambig":"","albumstatus":"","albumtype":"","albumtypes":"","arranger":"","artist":"the artist","artist_credit":"","artist_sort":"","asin":"","bitdepth":0,"bitrate":80000,"bpm":6,"catalognum":"","channels":1,"comments":"the comments","comp":1,"composer":"the composer","composer_sort":"","country":"","day":0,"disc":4,"discogs_albumid":0,"discogs_artistid":0,"discogs_labelid":0,"disctitle":"","disctotal":5,"encoder":"iTunes v7.6.2","format":"MP3","genre":"the genre","grouping":"the grouping","id":4,"initial_key":null,"isrc":"","label":"the label","language":"","length":1.071,"lyricist":"","lyrics":"the lyrics","mb_albumartistid":"","mb_albumid":"9e873859-8aa4-4790-b985-5a953e8ef628","mb_artistid":"7cf0ea9d-86b9-4dad-ba9e-2355a64899ea","mb_releasegroupid":"","mb_releasetrackid":"c29f3a57-b439-46fd-a2e2-93776b1371e0","mb_trackid":"8b882575-08a5-4452-a7a7-cbb8a1531f9e","mb_workid":"","media":"","month":0,"mtime":1638209521.0,"original_day":0,"original_month":0,"original_year":0,"r128_album_gain":null,"r128_track_gain":null,"releasegroupdisambig":"","rg_album_gain":null,"rg_album_peak":null,"rg_track_gain":0.0,"rg_track_peak":0.000244,"samplerate":44100,"script":"","size":12820,"style":"","title":"full","track":2,"trackdisambig":"","tracktotal":3,"work":"","work_disambig":"","year":2001}\n'
```

While the failing test is getting:

```
b'\n\n404 Not Found\n

Not Found

\n

The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.

\n'
```

Means that something is going wrong while setting up the data for this test. I suspect that the calling of Werkzeug under the hood needs to get adjusted so the test can succeed again.

### Setup

* OS: Debian testing
* Python version: 3.11.7 and 3.12.1
* beets version: 1.6.0
* Turning off plugins made problem go away (yes/no): not used

The people of NixOS have disabled the complete test for now: https://github.com/NixOS/nixpkgs/pull/263650/commits/20753def4b2099eaa1ef554b38a1d25ef89d5c7a

Start with WebPluginTest.test_get_single_item_by_path in test/plugins/test_web.py around line 142, then run that test with Werkzeug 2.3.8 or newer. Compare the expected JSON response with the 404 response and inspect the test setup involved; done means the test receives the item JSON and passes with the affected Werkzeug versions.

Written by the indexing model from the issue text.