That's indicating only support for the "Team Admin", not "Whole Team" mode. The description of the Team Admin mode is "The endpoint can access content of team folders but not team member's private files", which seems to match the behavior you're seeing.
Thanks for following up, and apologies for the confusion. Looking at this, I believe you're running in to a particular edge case, where the field names can be misleading.
The file for which you're getting the metadata in the first call is actually in a (different member's) home namespace, not a shared folder. Due to some implementation details though, that user's home namespace information is being returned in the file metadata as if it were a shared folder.
Then, the sharing endpoint in the second call is rejecting the ID since it's not technically a shared folder ID.
If you want to get the metadata for that parent folder, you can do so by calling /2/files/get_metadata for that namespace under that team's root namespace. Here's what that would look like in this particular case, in curl: