This is a known issue for custom attributes that are not part of the core schema if they aren't added to the provisioning schema in a certain way. Section 3.10 of RFC 7644 (https://tools.ietf.org/html/rfc7644#section-3.10) calls out:
In general, attributes are uniquely identified
by prefixing the attribute name with its schema URN separated by a
colon (":") character; e.g., the core User resource attribute
'userName' is identified as
"urn:ietf:params:scim:schemas:core:2.0:User:userName". Clients MAY
omit core schema attribute URN prefixes but SHOULD fully qualify
extended attributes with the associated schema extension URN to avoid
naming conflicts.
In this case, it's sort of a gray area given that phoneNumbers is a core schema attribute, but the type of "did" isn't explicitly mentioned in RFC 7643. Our provisioning engine I think is being a bit finnicky here as you've added just "phoneNumbers[type eq "did"].value". In instances where an attribute exists in the schema but we can't determine that it's a part of the core schema, there's some additional information(I can't recall the exact logic here) that we need that is returned to us by the SCIM service provider (the non-Azure AD side of this equation), so we can only do that after the object is already created. That in turn is leading to this behavior you're observing where we're not processing some attributes until the second pass after the object is created.
Try doing urn:ietf:params:scim:schemas:core:2.0:User:userName:phoneNumbers[type eq "did"].value and see if that works.