…#6812)

## Summary

#6552 added the unenforced clustering key to the schema format, but the
`UpdateConfig` transaction-apply path does not recompute the cached
`Field::unenforced_clustering_key_position` after applying field
metadata
updates — only `unenforced_primary_key_position` is recomputed (added
for the
primary key in #6706). The protobuf encoder reads the cached option, not
the
metadata HashMap, so installing or removing an unenforced clustering key
via
`update_field_metadata` does not round-trip.

This recomputes `unenforced_clustering_key_position` on apply, and
treats the
clustering key as a reserved, immutable schema property — mirroring the
unenforced primary key:

- once a clustering key is set, any commit that changes it, or that
writes its
  reserved metadata key, is rejected;
- writing the reserved key with a value that is not a valid position is
  rejected rather than silently ignored;
- a valid first install (single- or multi-column) and updates to other
field
  metadata are unaffected.

The check runs on every apply, including conflict-rebase, so it also
rejects
the concurrent-writer race.

`LANCE_UNENFORCED_CLUSTERING_KEY_POSITION` is also re-exported from
`lance_core::datatypes`, alongside the primary-key constants.

The metadata-update tests for both the primary and clustering keys are
restructured into individual tests with simpler `lance_datagen`-based
setup.