Firestore Collection List operation fails with "missing or insufficient permission"; Works for individual documents - google-cloud-firestore

Question

I'm trying to construct rules that allow a user to access all sub-collections and documents of a given account, if they are listed as a user of that account.
This works perfectly for retrieving individual documents, event nested ones. However, it fails when trying to list documents in a sub-collection.
This does not appear to me to be an instance of "rules are not filters": my query should categorically pass for every possible item queried, as it's based on their root ancestor document.
I've also read here (although I couldn't find it in the documents) that list operations also fail if you try and perform a get() for each queried document. I don't believe my rules violate this, either, as the get() command only needs to be run once, and will categorically return the same document for each queried document, as, again, it's based on a common ancestor.
Is my reasoning on the above rules wrong, or is there something else I'm not doing right?
My rules are as follows:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
function hasAccountPermission(request, path, permission) {
let accountId = path[0];
let account = get(/databases/$(database)/documents/accounts/$(accountId));
let role = account.data.users[request.auth.uid];
return (
request.auth != null
&& role != null
&& (permission == null || permission in account.data.roles[role])
);
}
match /users/{user} {
allow read, update, delete: if request.auth != null && request.auth.uid == user;
allow create: if request.auth != null;
}
match /accounts/{account=**} {
allow read: if hasAccountPermission(request, account, null)
allow write: if hasAccountPermission(request, account, 'all')
}
}
}
Example database is as follows:
/accounts/bobstuff
roles: {
admin: ['all']
}
users: {
bob: 'admin'
}
/docs/adocument
field: value
A get operation on /accounts/bobstuff/docs/adocument succeeds
A list operation on /accounts/bobstuff/docs/ fails

Answer 1

Ok. It turns out it was was violating the second principle - or at least, Firestore thought it was.
By changing the rules to capture the first path segment, instead of capturing the whole path, and extracting the first segment manually, it appears Firestore was able to determine that only a single get() would be required, and therefore, the rules were valid.
This required splitting the rule into {account} and {account}/{doc=**}. The side-effect of this is that I could also make the rules more efficient by avoiding a get() call for the root case.
Complete (working) rules:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
function hasAccountPermission(request, account, permission) {
let role = account.data.users[request.auth.uid];
return (
request.auth != null
&& role != null
&& (permission == null || permission in account.data.roles[role])
);
}
match /users/{user} {
allow read, update, delete: if request.auth != null && request.auth.uid == user;
allow create: if request.auth != null;
}
match /accounts/{account} {
allow read: if hasAccountPermission(request, resource, null)
allow write: if hasAccountPermission(request, resource, 'all')
allow create: if request.auth != null
}
match /accounts/{account}/{doc=**} {
allow read: if hasAccountPermission(request, get(/databases/$(database)/documents/accounts/$(account)), null)
allow write: if hasAccountPermission(request, get(/databases/$(database)/documents/accounts/$(account)), 'all')
}
}
}