feat: add tenant-rooted storage layout behind a setting #1863

[DmytroZaichenkoDev]

Part 2 of 4 for #1863. Stack: layout seam → this → secret AAD → end-to-end test.

What

Adds the tenant-rooted layout and selects the active layout at start-up.

• TenantRootedStorageLayout — the first consumer of part 1's conversion.
• StorageLayouts — holds the layout in force.
• AiDial chooses it from the new storageLayout settings section.

"storageLayout": {
  "tenantRooted": false,
  "defaultTenant": "default"
}

Invariant

Off by default, so physical paths are unchanged unless a deployment opts in. Documented in README.md alongside the other storage.* settings.

Notes for review

• The active layout is process-wide mutable state. ResourceDescriptor is constructed in ~63 files and carries no configuration, so there is nowhere else to put it without changing every construction site. Open to alternatives.
• AiDial sets the layout unconditionally on every start, including the legacy case, so the layout is always determined by settings rather than inherited from a previous start() in the same JVM — start() is @VisibleForTesting and runs repeatedly under test.
• storageLayout is a new top-level section rather than a field on storage: Storage is jclouds provider configuration, this is a logical concern. It is deliberately static settings, not hot-reloaded config.
• defaultTenant defaults to "default". That string becomes a physical path segment, so it is worth an explicit decision.

Not included

There is no migration behind this flag. Enabling it against populated storage re-addresses everything and the existing data is not reachable at the new paths. The README says so; a start-up guard that refuses to enable it when legacy data is present would be a reasonable follow-up.

[DmytroZaichenkoDev]

Folded into #1866 — the layout change now arrives complete (conversion, seam, implementation, setting) rather than split across two PRs where the first had no caller.