In https://privacycg.github.io/storage-access/#dom-document-hasstorageaccess, the only ways that the algorithm can return true are in step 10.3.5 or 10.3.6.

10.3.5

Step 10.3.5 is the "same authority" carveout. This is a bit loosely-defined, but the note mentions "same site checks while adhering to additional security aspects such as the presence of a cross-site parent document". I interpret this to mean that the inner and outer "A" documents in a A(B(A)) frame tree would not be same-authority. So, the algorithm wouldn't return here for an A(B(A)) frame tree.

10.3.6

Step 10.3.6 can only return true if permissionState is granted. permissionState is the result of getting the current permission state from the permission store, so the only way for that state to be granted is if some script previously requested permission to use "storage-access", and that step ultimately set a permission store entry with the appropriate key (i.e. a key where the top-level site and embedded site are both A).

Calling request permission to use is step 16.13 of document.requestStorageAccess(), so the permission could only be granted if control reaches that point of that algorithm.

However, step 16.7 of document.requestStorageAccess() checks if the embedded site and top-level site are same-site, and aborts the algorithm early if they are. So, if both the embedded site and top-level site are A, then the request permission to use invocation is unreachable. Thus the permission state is always prompt, and document.hasStorageAccess() is defined to always return false for that scenario.

I think this is not the behavior we want. https://github.com/web-platform-tests/wpt/blob/b84f9bdaa5e087aa5fe434d9c1bbf008176951cf/storage-access-api/requestStorageAccess.sub.https.window.js#L47 verifies that document.requestStorageAccess() can resolve and give access to cookies in an A(B(A)) frame tree, so I think it'd make sense for document.hasStorageAccess() to return true if the script does that.