Inconsistency between Service Health API and UI

- **Package Name**: azure-mgmt-resourcehealth
- **Package Version**: 1.0.0b6
- **Operating System**: Ubuntu and Mac (same behaviour on both)
- **Python Version**: 3.12.4

**Describe the bug**
When it comes to planned maintenances, there is inconsistency between what the Service Health UI reports vs the SDK.
On certain days, usually in the first couple days a new planned maintenance event is added, if I query the SDK to get planned maintenances it will return them pretty much as shown in the UI (even though the UI can be confusing).
But after those first couple days, whenever I query the API it will no longer return any planned maintenance. All this using the same code without any filter. Then that planned maintenance will only pop up again in the SDK after it is resolved. This makes it impossible for me to automate planned maintenance notification in my company's internal system.

**To Reproduce**
Steps to reproduce the behaviour:
1. Since my company has multiple subscriptions, I query for service health events like this:

```
from __future__ import annotations
import re
from azure.identity import DefaultAzureCredential
from azure.mgmt.resource.subscriptions import SubscriptionClient
from azure.mgmt.resourcehealth import ResourceHealthMgmtClient

# Regex captures any resource-id link in Service Health summaries (used mostly
# by PostgreSQL Flexible Server maintenance notices)
RESOURCE_ID_RE = re.compile(
r"/subscriptions/[a-z0-9-]+/resourceGroups/[^/]+/providers/[^\"']+"
)

cred = DefaultAzureCredential()
sub_client = SubscriptionClient(cred)

print("\n=== Azure Planned-Maintenance Debug Dump ===\n")

for sub in sub_client.subscriptions.list():
sub_id = sub.subscription_id
sub_name = sub.display_name or sub_id
print(f"\n{'='*8} Subscription: {sub_name} ({sub_id}) {'='*8}\n")

rh_client = ResourceHealthMgmtClient(cred, sub_id)

try:
events = list(rh_client.events.list_by_subscription_id())
except Exception as exc:
print(f"Failed to query events for {sub_id}: {exc}")
continue

if not events:
print("No events returned.")
continue

print(f"Total events returned: {len(events)}\n")

for ev in events:
print(f"Event ID: {ev.name}")
print(f" event_type: {getattr(ev, 'event_type', '')}")
print(f" category : {getattr(ev, 'category', '')}")
print(f" status : {getattr(ev, 'status', '')}")
print(f" start : {getattr(ev, 'impact_start_time', None)}")
print(f" end : {getattr(ev, 'impact_mitigation_time', None)}")
summary = getattr(ev, "summary", "")
if summary:
print(" summary :")
print(" " + summary.replace("\n", "\n "))
# Try to extract a resource-id from the HTML link (if present)
match = RESOURCE_ID_RE.search(summary)
if match:
print(f" extracted resource_id: {match.group(0)}")
```

This loops through all my subscriptions and lists events. Notice I'm not even applying any filter in the code. I got to a point where I removed all filters and still I do not see the open planned maintenances shown in the UI for the same list of subscriptions. I really suspect there is a bug here.

To make sure I wasn't getting crazy, I also ran this through AI. I showed AI the open planned maintenance events in the UI, then had it run a debug script using the SDK like the code above, and asked why there was difference, and it actually said to contact Azure support because there seemed to be inconsistency.

**Expected behaviour**
SDK to match what the Service Health UI reports for planned maintenances. The SDK seems to return Service Issue events properly, but not Planned Maintenances.

**Screenshots**

The AI conclusion I mentioned

**Additional context**
Not the type of issue that can be easily reproduced I must say. For example, our Azure Postgres Flexible Server maintenance windows are scheduled for Thursday mornings. Between Friday and Monday morning the SDK will report planned maintenances scheduled. By Monday afternoon it is gone. I don't know exactly if it is consistently only reported in some specific days or not, this is just my experience. In general though I've seen discrepancies that make the SDK nonviable.