Fix Copilot seat organization attribution causing wrong DORA adoption denominator

[bramhanandlingala]

Summary

Fixes #9041. Copilot seats from GitHub's enterprise API were being
tagged with the connection's "shell" org instead of the org that
actually granted the seat, which made the DORA dashboard's adoption
percentage wrong (often zero) for any org besides the shell org. Two
dashboard queries also mislabeled NULL adoption as the highest tier
instead of excluding it.

Root cause

• seat_extractor.go hardcoded every seat's organization to
  connection.Organization, ignoring the per-seat organization
  field the enterprise seats endpoint actually returns.
• Both DORA dashboards' adoption-tier CASE statements used ELSE as
  a catch-all, so NULL adoption silently got labeled >75% / high
  instead of being excluded.

Fix

• Parse the API's per-seat organization field
  (metrics_extractor.go) and prefer it over the connection's
  configured org, falling back only when the API doesn't supply one
  (seat_extractor.go).
• Replace ELSE with explicit WHEN + WHERE ... IS NOT NULL in
  both dashboards' tier queries (MySQL and PostgreSQL).
• Refactored seat parsing into a standalone function and added unit
  tests covering org-scoped, enterprise-with-org, and
  enterprise-with-empty-org cases.

Closes #9041

[anthonyhull-ford]

Thank you for creating a PR so quickly and for helping me investigate this issue.

Does this fix seats assigned through a central licensing organization?

The change stores seat.organization.login, which appears to identify the organization assigning the seat. If Central Licensing Org assigns a seat to a user who belongs to Product Org A and Product Org B, GitHub attributes usage to both product organizations, but the seat may remain attributed only to Central Licensing Org.

Would Product Org A and Product Org B still have zero denominators? Should licensed users be joined with organization membership, and could this scenario be added as a test?