There are different ideas what MVC means and where to put code. There is in my opionion an old view that describes that your main logic should be in the Controller, and your model should be thin, merely a way to access your data.

A newer idea is that your model should contain all your business logic and should be fat. That's why this approach is called fat model. Your Controller is the layer that communicates with your user and updates the view accordingly.

Let's describe it more general.

View
Contains everything for your View. In your example it's Swing. In more general you could say, its how your program represents data.

Model
All your business logic goes in here.

Controller
So what does the controller?

To better understand where to put code, you should make a thought experiment. This also makes it clearer, what the Controller does.

The thought experiment is simple. You not only want to create a desktop application for your buisness, you also want to create, let's say a Web Fronted and a CLI Tool. The goal is to achieve maximum code reuse.

The model in this experiment is a library that can be reused in your different applications. Let's say you want the typical CRUD operations for a Person. Then your model contains all those operations in a high-level idea to support it. Like

model.createPerson(...)
model.fetchPersonById(...)
model.searchPersons(...)
model.updatePerson(...)
model.deletePersonById(...)

It should not just be something like a database connection, that you query in your controller. And sure, you also add all other kind of functions that you need for your application.

The controller is just dump. It only determines what a user wants to do and then delegates it to the right model method/function.

You can think of the Controller as the thing, that communicates with the user. It handles whatever the user typed in, clicked in the UI, and so on.

Let's say you write a CLI program. Then your view would be some code that turns your model result into formated text for the user or turns it into something like JSON, CVS, whatever ...

The controller would be what parses the input or the command line arguments. Then call the model to do your thing, and then printing the result back to the user. Tell him the operation was completed, etc.

In a web application. The View is whatever you use to create your HTML.

The Controller would be something that maps a specific URL to a logic. For example that the url "/user/delete/id/1204" deletes the user with the id "1204" from your database.

In every of those examples. The model contains the logic of connecting to the database. Abstracting away your database. The model is not just data. Its what all your domain is about. And providing all the functionality you need in your application.

In every application there should be a simple line like

model.deleteUser(id)

that deletes the user. However it works. Back to your questions.

Should the Model contain a selectedPerson? The answer is no. Because in a model, there is no such thing as selection. Selection is what the view does. Not the model.

Your UI application can select something. But not the model.

If you want a different UI Element that somehow needs to know what the selected user is. Then yes. Also your new UI Element should watch on changes on the selection e.g. watch your Swing elements for changes. You also can create a selectedPerson property. But it should be part of the controller, never of the model.

But in my experience, you should fetch data directly. In my opinion there is no point in providing something like selectedPerson. Technically it is just a cache, that can be invalidated, and causes problems. If you want to know what is selected, then ask directly.

If it is much code to do this, then create a helper function/method that returns the selected User, but don't save it somewehere.

Summary

So in my opinion. Think of the model as a library that you can re-use in different applications.

For example, if i would write a command-line tool that i can call like: myapp --delete-user --id 1204

then something like selectedPerson makes no sense at all in a model, because there is no such thing as selection in a CLI. This makes it obvious that selection is from the view, not from the model.

If you want to search, then your model should also not contain a search text field. Provide something like

let results = model.search(searchPattern)

Your search method does all kind of searching and gives you a result, that you then can use to fill your UI. In a CLI you would turn the result into text and so on.