Don't use search endpoint to check for existence of models

Nobody has claimed this yet.

[discussion](https://metaboat.slack.com/archives/C064EB1UE5P/p1707405431922619)

On initial page load, we fire off a bunch of API requests, the single slowest of which is to the search endpoint (`/api/search?models=dataset&limit=1`) for the sole purpose of figuring out whether the instance has any models (we need to know this because we show different UI if you don’t have any models)

This feels pretty hacky, and I’m also pretty sure it’s a pretty heavy db operation

```
2024-02-08 15:10:51,644 DEBUG middleware.log :: GET /api/search 200 223.4 ms (5 DB calls) App DB connections: 1/10 Jetty threads: 5/50 (5 idle, 0 queued) (69 total active threads) Queries in flight: 0 (0 queued)
```

What if we moved this somewhere else, maybe something like has_models from /api/session/properties ? Would it make sense to persist this property instead of having every user run a big search query on every page load?

Start by tracing the initial page-load request to /api/search?models=dataset&limit=1 and the /api/session/properties entry point. Determine how the UI learns whether models exist, compare the database cost of the current search request with an alternative property, and verify that the resulting page-load behavior and empty-models UI remain correct.

Written by the indexing model from the issue text.