### reproduction setup
```sql
CREATE TABLE parent (id integer PRIMARY KEY, email text CONSTRAINT parent_email_key UNIQUE);
CREATE TABLE child (parent_email text REFERENCES parent(email));
CREATE INDEX parent_lower_email_idx ON parent (lower(email));
ALTER TABLE parent DROP CONSTRAINT parent_email_key;
```

### database response and state readback
```text
ERROR:  XX000: cannot drop index: `parent_email_key` is used by foreign key `child_parent_email_fkey`
         conname         | contype
------------------------+---------
 child_parent_email_fkey | f
 parent_email_key        | u
 parent_pkey             | p
(3 rows)
 schemaname | tablename |        indexname
------------+-----------+-------------------------
 public     | child     | child_parent_email_fkey
 public     | parent    | parent_email_key
 public     | parent    | parent_lower_email_idx
 public     | parent    | parent_pkey
(4 rows)
INSERT 0 1
ERROR:  23505: duplicate unique key given: [same@example.test]
```

The captured result expected SQLSTATE `2BP01` for the dependent-object rejection but observed `XX000`. The catalog readback retained the dependent foreign key, the unique constraint and its supporting index, and the unrelated expression index; the duplicate insert still failed with `23505`.

## Code Analysis

### Unique-constraint drops are routed through index dropping
`server/analyzer/resolve_drop_constraint.go:93-98`
```go
if index.ID() != "PRIMARY" && index.IsUnique() && index.ID() == dropConstraint.Name {
	// DropIndex reacquires the database by name and loses the target schema. AlterIndex
	// retains the schema-qualified database and also handles expression-index cleanup.
	newNode, err := plan.NewAlterDropIndex(rt.Database(), rt, dropConstraint.IfExists, index.ID()).
		WithTargetSchema(rt.Schema(ctx))
	return newNode, transform.NewTree, err
}
```
For a named non-primary unique constraint, the analyzer replaces the constraint drop with an `AlterDropIndex` plan. That provides a concrete production path for the observed index-dependency error; the runtime readback shows the rejection remained atomic.

### PostgreSQL dependent-object code exists
`postgres/parser/pgcode/codes.go:185-187`
```go
// Section: Class 2B - Dependent Privilege Descriptors Still Exist
DependentPrivilegeDescriptorsStillExist = MakeCode("2B000")
DependentObjectsStillExist              = MakeCode("2BP01")
```

`server/extensions/objects.go:367-370`
```go
if finder.found {
	return pgerror.Newf(pgcode.DependentObjectsStillExist,
		"cannot drop extension %s because other objects depend on it", e.ext.Name)
}
```
The repository defines `2BP01` and uses it when dependency checks reject an operation, while this unique-constraint/index path does not perform a corresponding translation in the cited analyzer code.

### Result
The captured execution supports REV-3's reported error-contract failure: the dependent constraint drop was safely rejected and preserved catalog state, but returned `XX000` instead of the required `2BP01`. The duplicate insert's `23505` response confirms the unique constraint remained effective.

### Test context
The run used the local database engine with no mocks, stubs, or bypasses. The source excerpts explain the likely production path; the error code and catalog state above are directly captured runtime evidence.