post-validation cleanup fails every time, leaving an orphaned `_acme-challenge` TXT record with dns_efficientip.sh

**Issue: post-validation cleanup fails every time, leaving an orphaned `_acme-challenge` TXT record:**

**Root cause and fix for the `dns_efficientip` cleanup failure**

I dug into this and traced the cause. Posting it here since I'm preparing a PR.

**Symptom:** issuance succeeds, but the post-validation cleanup fails every time, leaving an orphaned `_acme-challenge` TXT record:

```
Removing txt: for domain: _acme-challenge.
Using EfficientIP API
DELETE
_post_url='.../dns_rr_delete?rr_type=TXT&rr_name=_acme-challenge.&rr_value1=&dns_name='
Error deleting DNS record
{"connected":false}
```

The `dns_rr_add` call just seconds earlier — same `dns_name`, same credentials — succeeds. So it isn't auth or connectivity.

**Cause:** `dns_efficientip_rm` deletes by `rr_name` + `rr_value1`. On a SOLIDserver smart architecture, the appliance stores the FQDN in `rr_full_name`, with the relative label in `rr_glue`. You can see this in a `dns_rr_list` response for the challenge record:

```
"rr_full_name":"_acme-challenge.host.example.com",
"rr_glue":"_acme-challenge.host",
"rr_name_id": ...,
"rr_id":"58337702"
```

A delete keyed on `rr_name=` doesn't resolve to a unique record, so the API no-ops and returns `{"connected":false}` — which isn't a documented SOLIDserver error shape, hence the unhelpful message.

Deleting by `rr_id` works cleanly. Manually confirmed against the same appliance:

```
GET /rest/dns_rr_list?WHERE=rr_full_name='_acme-challenge.host.example.com' and rr_type='TXT'
→ [{... "rr_id":"58337702" ...}]
DELETE /rest/dns_rr_delete?rr_id=58337702
→ [{"ret_oid":"58337702"}] (HTTP 200)
```

This matches the vendor's own documented delete example (REST API Reference, Example 36.4), which deletes by `rr_id`.

**Fix (PR incoming):** change `dns_efficientip_rm` to do the documented two-step:

1. `dns_rr_list` filtered on `rr_full_name` + `rr_type='TXT'` + `value1=''` to resolve the `rr_id`.
2. `dns_rr_delete?rr_id=`.

I've tested this end-to-end on a production smart architecture (`dns_type: vdns`, no view) against LE staging — full add → verify → remove cycle completes with no orphan left behind, where the stock plugin failed on every removal. PR to follow against `dev`.

The issue is in the dns_efficientip.sh DNS plugin. Start by reading the plugin's dns_efficientip_rm function to understand the current delete logic. The fix involves adding a dns_rr_list call to get the rr_id using rr_full_name and rr_type='TXT', then performing a dns_rr_delete with that rr_id. Test the change by running the plugin's add and remove cycle against a staging environment to ensure no orphaned records remain.

索引モデルが issue の本文から書いたものです。