Stale credentials prevent direct verification of bucket access

[drernie]

After quiltx bucket add ... succeeds (registration + S3 policy + SNS),
we used to verify access by calling quilt3.Bucket.ls() against the
freshly-added bucket. That fails in legitimate scenarios because:

• quilt3.Bucket.ls() resolves credentials via
  quilt3.session.get_boto3_session(), which returns user-scoped
  STS credentials cached locally from the most recent Quilt session.
• Those creds are scoped by the user's role's session policy at the
  moment they were issued. If the user's role doesn't grant access to
  the new bucket, or if the cache predates an ACL change, b.ls()
  raises AccessDenied even though the bucket-add itself succeeded
  server-side.
• The failure message previously said "via control account", which is
  false — those creds are user-scoped, not control-account-scoped.

Workaround applied in 7c16ffa: drop the direct access check; keep
registration lookup and search-index probe.

Open question: is there a useful access check we can run that
isn't subject to local credential staleness? Options to evaluate:

1. Have the catalog backend perform the access probe and report back
   (requires a new GraphQL query / admin endpoint).
2. Use explicit control-account boto3 credentials (new
   --control-profile flag) and call head_bucket cross-account.
3. Force a fresh STS issuance before the check (clear local cache).