fix(api): bytes head entity headers

[gacevicljubisa]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

HEAD /bytes/<ref> did not return usable entity headers. Three separate defects:

1. Invalid Content-Length. The redundancy level is packed into the most significant byte of the root chunk span (redundancy.EncodeLevel), so reading the span as int64 yielded a negative number for any upload with redundancy level >= 1 spanning more than one chunk. Bee sent Content-Length: -9151314442816647872; curl rejects that and aborts header parsing (exit 8), which is why the response looked like it had no headers at all.
2. Encrypted references returned 404. The handler looked up the full 64-byte reference (address + key) as if it were a chunk address.
3. Accept-Ranges was never sent on HEAD, for /bytes or /bzz, even though both serve ranged GETs.

bytesHeadHandler now delegates to downloadHandler with headersOnly, the same path bzzHeadHandler already uses. HEAD and GET therefore share one implementation and the length comes from the joiner, which strips the encoded redundancy level and splits an encrypted reference into address and key. Accept-Ranges is set on that shared header-only branch, so both endpoints are covered.

Behavior change worth noting: HEAD now reports the same status as GET for references that cannot be served, where it previously always returned 404. Pinned by TestBytesHeadErrorsMatchGet.

Open API Spec Version Changes (if applicable)

Documented Accept-Ranges, ETag and the 500 response on HEAD /bytes/{address} and HEAD /bzz/{address}.

info.version left at 8.1.0. The added response headers are additive, but the HEAD status change above is arguably breaking — happy to bump if you would rather record it.

Motivation and Context (Optional)

Size-then-range is how generic HTTP clients read a large remote object: HEAD for the length, then ranged GETs. Bee's ranged GET support already works, so the missing HEAD headers were the only thing blocking that whole class of client (nbdkit, rclone, aria2, anything on libcurl's remote-file handling).

Related Issue (Optional)

Closes #5545

Screenshots (if appropriate):

AI Disclosure

• This PR contains code that has been generated by an LLM.
• I have reviewed the AI generated code thoroughly.
• I possess the technical expertise to responsibly review the code generated in this PR.

[martinconic]

Early-returning 200 OK here bypasses Go's http.ServeContent, which causes HEAD requests containing a Range header (e.g. HEAD /bytes/ with Range: bytes=0-99) to return 200 OK with the total content length and no Content-Range header.

In contrast, a GET request with Range: bytes=0-99 returns 206 Partial Content with Content-Range: bytes 0-99/ and Content-Length: 100.

According to RFC 9110 Section 9.3.2, HEAD requests must return identical entity headers to GET. Conditional HEAD requests (If-None-Match, If-Modified-Since) also fail to return 304 Not Modified for the same reason.

[martinconic]

Could we add a test case to TestBytesHead for HEAD requests with a Range header (e.g. Range: bytes=0-10)?