fix(advanced-marker): only assign anchorLeft/anchorTop when provided

[simonyang08]

Fixes #867

Summary

When the consumer supplied only one of anchorLeft or anchorTop to <AdvancedMarker>, useAdvancedMarkerAnchoring unconditionally assigned undefined to the other side, clobbering the default value the Google Maps JS API had set up on the underlying AdvancedMarkerElement. Combined with gmpDraggable = true, the API subsequently threw

TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node'

while wiring up the drag handle.

The fix only assigns each property when the consumer actually provided it, leaving the unprovided side untouched.

Reproduction

<AdvancedMarker
  position={{lat: 0, lng: 0}}
  draggable
  anchorTop="-90%"
>
  <img src="pin.svg" alt="pin" />
</AdvancedMarker>

Removing anchorTop or supplying both sides avoids the crash. This matches the reporter's findings ("removing the prop doesn't cause the crash", "in a closed environment it works").

Changes

• src/components/advanced-marker.tsx: guard the two assignments so each runs only when the corresponding prop was provided by the consumer.
• src/components/__tests__/advanced-marker.test.tsx: regression test verifying the unprovided anchor side has no own-property descriptor after rendering.

Test

• npx jest → 20 suites passed, 157 tests passed (plus pre-existing todos unrelated to this change).
• npx tsc --project tsconfig.test.json --noEmit → exit 0.
• npx eslint / prettier --check on changed files → clean.

Notes for reviewer

• The full crash only manifests with the real Google Maps JS API + draggable; the jest-mocks backend cannot reproduce the appendChild TypeError. The regression test therefore locks the deterministic root-cause invariant: after rendering with only anchorTop, the marker must not own an anchorLeft property (on main this assertion fails with value: undefined).
• Known limitation: dynamically removing a previously provided anchor prop now leaves the previous value in place until the marker is rebuilt (map/library/children changes rebuild the instance). On main that same scenario writes undefined — the crash form this PR fixes — so neither version implements a reset-to-default semantic; remount if a reset is needed.
• Related: src/components/3d/marker.tsx (Marker3D) has the same unconditional-assignment pattern via usePropBinding; left out of this focused fix — happy to file a follow-up.

[usefulthink]

this is actually looking good already, is there anything else you want to add?

My only comment would be that I just noticed that the fallback logic for older versions (we had our own implementation of this before the maps API added it) can now be removed since there no longer is a google maps version that doesn't support it natively.

@mrMetalWood can you have a look at that?

Besides that, I think we could already merge this.

[usefulthink]

while we're at it, we can now remove the support for older versions without these props.