[BUG] secondary parent `hash_string` copy lacks the `MAXDNAME` bound already used for `hostname`

I would like to report what appears to be the same current-head overflow pattern in the secondary-parent branch of `ParentSelection.cc`. I rechecked current upstream head on 2026-03-10 before writing this report.

As in the primary-parent case, current head checks the hostname length but not the `&hash` suffix length. The secondary branch is:

```c
memcpy(this->secondary_parents[i].hostname, current, tmp - current);
...
if (tmp3) {
memcpy(this->secondary_parents[i].hash_string, tmp3 + 1, strlen(tmp3));
this->secondary_parents[i].name = this->secondary_parents[i].hash_string;
}
```

and the destination is again:

```c
char hash_string[MAXDNAME + 1];
```

inside `struct pRecord`.

I am intentionally making the same narrow claim as for the primary branch:

- local configuration parsing bug
- not a remote HTTP issue
- overflow condition depends on an overlong `&hash_string` suffix in parent configuration input

Why I think it is still a real bug:

- the only explicit `MAXDNAME` check in this parsing block applies to `hostname`
- the secondary `hash_string` copy has no corresponding bound
- `pRecord` instances are stored in arrays, so the overflow does not stop at a harmless tail buffer

This branch should receive the same fix as the primary-parent branch: reject overlong hash suffixes before the copy.

Best regards,
Pengpeng Hou
ISCAS