Hub database guide does not say how the schema's columns nest

🐛 Problem

src/queries/finops-hub-database-guide.md defines each column on its own, but never says how the columns nest. A reader who has a breakdown by ServiceCategory and wants to drill into it has nothing in the guide to follow, and no way to tell which of the available columns is "one level down".

Searching the guide for hierarch returns a single hit, and it is the financial hierarchy inside an example query — not the organizational or service structure.

This matters most for the service columns, because there are two chains and they are easy to mistake for one:

FOCUS:  ServiceCategory -> ServiceSubcategory -> ServiceName
Azure:  x_SkuMeterCategory -> x_SkuMeterSubcategory -> SkuMeter

They are parallel classifications. A single meter category can sit under several service categories, so drilling from one chain into the other does not partition anything, and a meter category's total is not a subset of any one service category. Nothing in the guide warns about this.

👣 Repro steps

Costs()
| where ChargePeriodStart >= startofmonth(ago(30d))
| summarize ServiceCategories = dcount(ServiceCategory) by x_SkuMeterCategory
| where ServiceCategories > 1
| order by ServiceCategories desc

Run on two unrelated hubs, this returns a non-empty result on both — meter categories that map to more than one service category, some to eight.

🤔 Expected

A short section stating the organizational chain, the two service chains, and the fact that they do not nest — so a reader can drill down without inventing a structure.

🔧 Environment

• Affected file: src/queries/finops-hub-database-guide.md on dev
• FinOps hub version: any

ℹ️ Additional context

PR follows. Related but filed separately: the same guide's Costs() table reference has drifted from the deployed schema.

Read src/queries/finops-hub-database-guide.md and review the provided Costs() query to understand the two parallel service classifications. Add a short section covering the organizational chain, both service chains, and why they do not nest. Done means a reader can identify valid drill-down paths without confusing the classifications.