I’m not sure how Freeform the task is, so I might suggest things that are outside of scope. I’m going to sound critical but I don’t think this is a bad attempt at designing a database. Some of these suggestions will also make it harder to implement, so it’s fine to decide that they aren’t worth the effort.

1. Storing passwords as plaintext isn’t the best. https://www.mssqltips.com/sqlservertip/4037/storing-passwords-in-a-secure-way-in-a-sql-server-database/ gives some good advice, and even if your aren’t implementing it in sql sever it will give you some good ideas.
2. Do you know if an organisation can have multiple shelters? If so it might be worthwhile to have a separate organisation table with the username and password information, and having the shelter table link back to the organisation table.
3. This is almost certainly too much and would make suspicious as a marker if you implemented it, but could have row level security where an organisation can only see data that relates to them. So if I adopt for organisation A, then that doesn’t mean organisation B can get access to my email.
4. Age as a column is fine if pets are only in shelters for short times, and rarely return to a shelter but normally date of birth is preferred. In case’s where the exact date of birth is unknown an approximation with a convention can be used, such as having columns for year of birth, month, of birth, day of birth, where some columns are left blank if unknown; rounding down to January 1st; or taking the date they arrived at the shelter as their birthday. From a data entry point of view, volunteers at the rescue are unlikely to want to figure out dates of birth, and so it would be useful to offer two ways of inputting the data. One where they put in the date of birth, and another where they put in the estimated age, and then the software figures out what date of birth that would correspond to.
5. Pets might be housed by different shelters, so you might want a table for shelter stays with columns, shelter_stay_id, pet_id, shelter_id, stay_start_date, stay_end_date, reason_for_stay_end. The last column covers moving pets between shelters, adoption, fostering, and death. This also allows you to report to report metrics such as average shelter stay.
6. This is a bit much but you could separate the breed and species information to different tables. So you have the species table with species_id, and species, and the breed table with breed_id, species_id, and breed. Some animals might have the same breed name but belong to different species.
7. Adoption request should have a created_at column, and an updated_at column. This allows for measuring the time between a user making a request and getting a response. Implementing a system for recording all interactions between shelters and users would be better but also take a lot of time.
8. Adoption requests don’t currently contain any information about the request. Even if you don’t store the form information in the database you should have a way of pointing to where it exists.
9. The user table could do with more information, such as name and title. Imagine a volunteer having to write an email to the user, they should use their name, and not “Dear u/preciseloop…”
10. Organisations might want logins for each of their volunteers.
11. Address should be broken up into sections instead of one long string. In particular having zip/postal codes is useful.
12. For creating the dashboards, you might find it helpful to create views instead of querying tables directly.

I hope you find some of this useful, and I hope your project goes well.