Reject NodeCreate and NodeUpdate transactions with duplicate endpoints

### Background

On mainnet, the current address book contains duplicate service endpoints in node 7 and node 34. This can cause transactions to be rejected with `INVALID_NODE_ACCOUNT`.

### Acceptance Criteria

1. Submit a NodeCreate or NodeUpdate with a service endpoint that is already present in the address book
2. The transaction should fail during consensus

--

1. Submit a NodeCreate or NodeUpdate with a web proxy endpoint that is already present in the address book
2. The transaction should fail during consensus

--

1. Submit a NodeCreate or NodeUpdate with a gossip endpoint that is already present in the address book
2. The transaction should fail during consensus

### Dependencies

_No response_

### Definition of Ready (DoR) Checklist

- [ ] Clear acceptance criteria
- [ ] Clear and detailed description
- [ ] Dependencies identified
- [ ] Links to documentation
- [ ] Should be completable in 2-3 Days
- [ ] Initial draft of Low-level design document
- [ ] At least high level test plan
- [ ] Groomed/Estimated

### Definition of Done (DoD) Checklist

- [ ] Acceptance Criteria complete
- [ ] No Codacy issues greater than minor (in new code)
- [ ] JavaDocs updated/created
- [ ] Code commented
- [ ] Unit tests created/updated
- [ ] 80% test code coverage (in new code)
- [ ] Happy Path and major negative cases in HAPI tests as applicable

Start by locating the NodeCreate and NodeUpdate transaction handling and the address-book endpoint validation path. Trace how service, web proxy, and gossip endpoints are checked during consensus, then add or update tests showing that each duplicate endpoint type is rejected with the expected failure.

Written by the indexing model from the issue text.