There are two obvious missing items from your list of considerations: the definition of "done" and the team's own opinion itself of its capacity. There is a simple exercise you can use to help the team with this that I have called "commitment based Sprint planning". It goes as follows:
First, present the team with the other information you mentioned in your question so that everyone is aware of that data.
Second, visually establish/update the definition of "done". This may take quite a long time if the team has not previously made this explicit. Examples of things in the definition of "done" include technical quality, bureaucratic activities, release activities, user and business quality, security, documentation, etc.
Third, repeat the following steps until any member of the team shows uncertainty either by voice or by facial expression:
- Present the team with the next Product Backlog Item (PBI). If this is the first round through these steps then this is the PBI that is at the top of the backlog.
- Give the team a short time (usually 5 minutes max) to discuss the meaning and implementation of the PBI and ask the Product Owner clarifying questions.
- Ask the team: can you commit to completing this item (and any already agreed) in the current Sprint?
- If every member agrees, then the item is added to the list of items in the team's capacity for the Sprint. If any member disagrees or shows significant uncertainty, then stop. NOTE: team members should not be pressured to agree - the decision to accept a PBI must be unanimous!
Finally, look at the PBIs that are put into the agreed pile and do a sanity check with the team: given the definition of "done", can the team unanimously agree that all of these items can be completed by the end of the Sprint? If the answer is still "yes" then this is the capacity of the team. If there is uncertainty, then the team works to split some of the larger PBIs into smaller ones and removes small amounts of work until there is unanimous agreement.
NOTE: At no point in the discussion should individual team members be volunteering for specific pieces of work, nor should estimating be done based on individual availability.
Conclusion
The word "capacity" is often thought of as person-hours. This is a false understanding of capacity when one is working in a complex problem environment. Instead, capacity can be thought of as the team's ability to apply its expertise to specific problems. The framework I have described above does not give you a "person-hours" measurement. Instead, it gives you a direct measure of the team's ability to apply its expertise to a specific set of problems (the PBIs) in a specific amount of time (the Sprint).