There is no concept of "team ownership" of workitems in Azure DevOps. Instead the each workitem belong to an Area Path. Area paths can then be added to one or multiple teams (see Add area path to team). The workitems belonging to Area Paths of a team is what is shown on the teams board.
In order to achieve what you describe you need to first ensure that each team has their own area paths that are not shared with any other team (there is no limitation against this in Azure Devops as is). Once there are no shared Area Paths you can set permissions on the area paths
Area path permissions let you grant or restrict access to edit or
modify work items, test cases, or test plans assigned to those areas.
You can restrict access to users or groups. You can also set
permissions for who can add or modify areas or iterations for the
project.
I would recommend to remove all permissions from the root area path so that no permissions are inherited and assign only View Workitems in this node and Edit workitems in this node to the team that is owning the area path. While it is technically possible to leave the root area permissions as is and deny the abovementioned permissions for all other teams instead, that quickly becomes an administrative overhead and source of error (for example, adding a new team would require all existing area paths to be updated in such a scenario)
I would still recommend evaluating the single project setup even though it is a recomendation from Microsot. Your strict boundaries that do not even allow read access between workitems voids many of the advantages of the single project setup unless you are setting up some hierarchial team structure where a management team has access into multiple area paths and thus can view an aggregated board or do cross team searches.
Another thing to consier when having multiple teams that essentially work in silos in the same project is how tags work. The tags are project wide and thus a tag taht is created by team A will show up in the list of tags also for Team B (in autocomplete fields etc), which can be confusing.