Driver-model fidelity gaps across the #143 SDK-compat slices (list scope, upsert updates, ordering, Azure IDs)

[NitinKumar004]

Follow-up from the code review of the #143 SDK-compat slices (LB #254, Event Bus #255, Logging #256, Cache #257, Notification #258). The self-contained correctness bugs were fixed in those PRs; the items below are recurring limitations rooted in the shared service-driver abstractions, so they affect the Portable API too and are best fixed once at the driver layer rather than per-handler. (Companion to the DNS follow-up #253.)

Cross-cutting driver-model gaps (seen in most/all slices)

• Scope-less List*. logging.ListLogGroups, eventbus.ListEventBuses, cache.ListCaches, notification.ListTopics take no scope arg, so the Azure ListByResourceGroup / ListBySubscription (and GCP per-project list) handlers return every resource regardless of resource group / subscription / project, and Azure re-labels them under the requested scope. Needs scope-aware driver lookups.
• No Update → tag/field drop on upsert. Azure CreateOrUpdate on an existing EventGrid topic / Log Analytics workspace / Redis cache / Notification Hub namespace silently discards the request's new tags / retention / SKU and echoes the stored resource with 200. Same class as DNS DNS driver-model fidelity gaps (zone scoping, UpdateZone, TXT chunks, batch atomicity) #253. Needs an Update* (or upsert) driver method.
• Nondeterministic list ordering. All List* iterate memstore.All() (a Go map), so multi-item responses come back in random order (real APIs default to a defined order, e.g. reverse-time for log entries). Repo-wide pattern (DNS/route53 too) — worth a deterministic sort at the memstore/driver layer.
• Azure resource IDs baked from a fixed rg-default. providers/azure/loganalytics (and peers) build ResourceID from a hardcoded resource group / account, so the ARM id (and customerId) returned don't match the request's subscription/RG. Handlers should rebuild the ID from the request path via azurearm.BuildResourceID (as the DNS handler does).

Per-slice items deferred here (not quick self-contained fixes)

• Event Bus (AWS): PutEvents can't report per-entry results — the driver's PublishResult exposes only FailCount, not which entries failed, so a partial-failure batch can't return len(input) aligned entries with per-entry error codes as real EventBridge does. Needs per-entry results on the driver.
• Cache (GCP): Memorystore's handler claims /v1/projects/{p}/locations/{l}/operations/{op}, which overlaps GKE's operations path (GKE registers first). Latent today because Memorystore LROs return done:true inline so the SDK never polls; still, the {instances|operations} "disjoint" docstring is inaccurate and GET …/operations (collection) returns a fabricated done-op. Narrow Memorystore to instances-only or make operations service-aware.
• Notification: FCM token/condition-addressed sends funnel into one global _fcm_token_target topic (docstrings claim per-project/per-request); SNS GetTopicAttributes omits always-present attributes (SubscriptionsPending, Owner, …).
• Logging (GCP): entries:list with a logName filter but absent/mismatched resourceNames yields logName: projects//logs/<id> (empty project); malformed entry timestamps are silently coerced to ingest-time now.

Acceptance: extend the affected driver interfaces (scope-aware list, Update, per-entry publish results), rebuild Azure IDs from the request path, and add deterministic ordering; update all providers + handlers and add roundtrip tests covering per-scope listing, tag updates, and ordering.