[Maps] Restore original ts-expect-error for complex style type intersection for BlendedVectorLayer

[olapawlus]

Closes #187897

These two TypeScript errors were marked as after the upgrade, but it turns out that the file already contained a ts-expect-error before the upgrade, which makes it very likely that these issues are not caused by the TS upgrade, but come from the existing code.

This is also the only case in the PR upgrading the TS where the file blended_vector_layer.ts already contained a ts-expect-error before the upgrade - see the link, which makes it very likely that the new comment about the upgrade-related error was added by mistake.

I tried to fix the issue, but the type intersections here are very complex, and solving this properly would require a larger refactor. Because of that, I suggest restoring the previous TypeScript comment and removing the note about the upgrade, since the error wasn’t introduced by the new TypeScript version.

The problem concerned the type StylePropertyOptions / DynamicStylePropertyOptions / StaticStylePropertyOptions, which are a combination of many possible shapes using a large union + intersection of types.
When cloning styles (e.g., copying properties into clusterStyleDescriptor.properties[styleName]), TypeScript reported that the created object does not satisfy all the properties required by this huge intersection, for example:

• missing fieldMetaOptions
• missing minSize
• missing maxSize
• missing several fields depending on the specific style variant

In other words:

TS tried to match the object to the fully “merged” types, which in practice never exist together, because at runtime many variants are allowed, but TS treats the intersection very strictly.

Therefore, the only realistic solution was:

• accept a ts-expect-error

  or

• change the entire type system (which was not the goal of this PR)

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[nickpeihl]

Thanks for the thorough analysis. Do you mind adding a summarized reason to both @ts-expect-error?

Suggested change

	// @ts-expect-error
	// @ts-expect-error <description why we ignore type error>