fix: don't render nil JsVar Ptr through value-receiver callbacks (#196)

[linkdata]

Summary

Fixes #196. Rendering a JsVar bound to a nil pointer could panic and then permanently retain the shared application lock.

JawsRender passed the typed-nil Ptr to Element.ApplyGetter. Because a typed-nil pointer is a non-nil interface, ApplyGetter recognized tag.TagGetter and called its value-receiver JawsGetTag through the nil pointer, causing a runtime panic. The write lock was released with a bare Unlock (not a deferred one), so the panic unwound past it and left the locker held forever — stalling every goroutine sharing that application state.

Fix

• Extract the render-time critical section into renderSnapshot, which holds the write lock under a defer Unlock(). A panic from a supported bound-value callback or from marshaling can no longer leak the lock.
• When Ptr is nil, skip the bound-value getter/init callbacks and omit the initial data — the behavior NewJsVar already documents ("reads return the zero value, rendering omits the initial data").

Behavior for a non-nil Ptr is unchanged (same getter value passed to ApplyGetter, same lock scope covering ApplyGetter + marshal so the serialized value stays consistent with the dirty tag).

Tests

Two regression tests, both verified to fail on the pre-fix code and pass after:

• TestJsVar_RenderNilPointerWithTagGetterDoesNotLeakLock — the exact scenario from Rendering a nil JsVar pointer can panic and permanently retain its lock #196 (nil pointer to a type with a value-receiver JawsGetTag); asserts no panic, lock released, and no data-jawsdata.
• TestJsVar_RenderMarshalPanicDoesNotLeakLock — a bound value whose MarshalJSON panics; asserts the panic propagates but the lock is still released.

go test -race ./... passes across the module; go vet, gofmt, and staticcheck are clean on the touched files.