Gate instrument registration behind operator propose-accept #28

User story / Problem statement

Currently any admin can register an instrument directly, so nothing prevents two InstrumentConfig contracts from sharing the same (admin, instrumentId). LF 2.1 has no contract keys, so this cannot be prevented by a Daml key, and a duplicate instrument id would make every registry lookup ambiguous.

Expected outcome

An admin proposes an instrument and the operator accepts or rejects it. The operator becomes the governance gate that enforces (admin, instrumentId) uniqueness, and the direct registration path is removed so the gate cannot be bypassed.

Acceptance criteria

• InstrumentConfigProposal exists, created by the admin
• The operator can accept a proposal, producing the InstrumentConfig, or reject it
• The direct registration choice is removed, so propose-accept is the only path
• Uniqueness of (admin, instrumentId) is enforced at accept time
• Tests cover accept, reject, and an attempted duplicate registration

Technical notes

Uniqueness cannot be atomic on-ledger without keys. It is enforced by the accepting party reading active configs before accepting, which is safe because a single operator serializes acceptance, and it is backstopped by a conflict response on the read side of the registry service.

Additional context

Part of #20. Implemented by #5.