`microsoft.graph.managedDevice` is missing a filter restrictions annotation.

[esidorenko-sl]

Filtering is only partially supported on /deviceManagement/managedDevices (microsoft.graph.managedDevice), but there is no Org.OData.Capabilities.V1.FilterRestrictions annotation on the type or on the deviceManagement/managedDevices navigation property. The only place the restriction is recorded is the type description:

Devices that are managed or pre-enrolled through Intune. Limited support for $filter: Only properties whose descriptions mention support for $filter may be used, and combinations of those filtered properties must use 'and', not 'or'.

With FilterRestrictions absent, Filterable defaults to true, so the metadata advertises the collection as fully filterable. Generated clients follow the metadata: Get-MgDeviceManagementManagedDevice exposes -Filter and the .NET client exposes Filter on the request configuration, with no machine readable signal about which properties actually work. Today a caller has to read the description of each property one at a time to find out.

The per property descriptions already record which properties support $filter, so the information needed for the annotation is already in the metadata.

Same shape as #225, which was fixed by #227.

[esidorenko-sl]

I got access to a tenant with Intune and checked what the service actually does. It rejects the undocumented properties outright rather than ignoring them, which lines up with the annotation being the missing piece.

Requests against /v1.0/deviceManagement/managedDevices:

$filter	Documented as filterable	Result
deviceName eq '...'	yes	200
model eq '...'	yes	200
userId eq '...'	no	400 Unsupported parameter found in query
wiFiMacAddress eq '...'	no	400 Unsupported parameter found in query
notes eq '...'	no	400 Unsupported parameter found in query
id eq '...'	no	400

So the service knows exactly which properties can be filtered and says so at request parse time, before it looks at any data. The tenant I used has no enrolled devices, which does not matter for the 400 cases since the query never gets that far.

This is the same behaviour that #225 described for directorySetting, where filtering also failed with a 400 and the fix was to add the annotation.