fix(statics): scope FindBucket to the app's org

[jphenow]

Summary

• statics.FindBucket was calling the top-level addOns(type: tigris) GraphQL query, which returns every tigris add-on the caller can see across every org and then filters client-side by org slug + metadata pointer. For accounts with a lot of tigris add-ons this stalls fly apps destroy (and fly apps move), since both run FindBucket before doing anything useful.
• Adds a new ListOrganizationAddOns($orgSlug, $addOnType) query (web's Organization.addOns(type:) already supports this) and switches FindBucket over. We still match the specific bucket by the app_id metadata pointer — existing statics buckets aren't linked via add_ons.app_id, so org-scope is the tightest we can get without a backfill.
• Drops the now-redundant client-side org-slug filter and introduces a statics.Bucket type alias so callers don't have to name the generated type directly.

Follow-ups (separate PRs)

1. Set params.AppName in ensureBucketCreated so new statics buckets are linked to their app via add_ons.app_id.
2. Once (1) ships, tighten FindBucket to query App.addOns(type: tigris) (via the existing GetAppWithAddons) and keep the org-scoped query as a legacy fallback.

Test plan

• go build ./... (passes locally)
• go vet ./internal/command/deploy/statics/... ./internal/command/apps/... ./gql/... (passes locally)
• Manual: fly apps destroy on an app that does have a statics bucket — confirm the bucket is still cleaned up.
• Manual: fly apps destroy on an app without a statics bucket in an org with many tigris add-ons — confirm it returns quickly instead of timing out.
• Manual: fly apps move on an app with a statics bucket — confirm the bucket still gets migrated to the new org.

[jphenow]

Wound up solving this better with #4827 which defaults new statics to link directly to an app then falls back to what this was doing anyways.