Remove ACT support from SOC and chunk endpoints

[nugaon]

ACT (Swarm-Act header) is currently accepted on POST /soc/{owner}/{id} and POST /chunks, but in both cases it is either semantically broken, end-to-end non-functional, or misaligned with the purpose of those endpoints.

---

POST /soc/{owner}/{id} — remove ACT

1. Data is never encrypted. The SOC chunk is stored in plaintext before ACT runs. ACT then wraps only the reference, not the payload.
2. Reference protection is meaningless. A SOC address is deterministically derived from owner + id and publicly computable — encrypting a reference to it provides no protection.
3. Logical inconsistency. putter.Done is called on the original SOC address, but an ACT-encrypted address (a different address space) is returned to the caller.
4. No decryption path exists. GET /soc/{owner}/{id} has no ACT decryption middleware at all. There is no way to resolve an ACT-wrapped SOC reference back to its canonical endpoint, making any upload with Swarm-Act on this endpoint completely unusable end-to-end.

The owner-based signing model of SOC already provides a natural identity/access primitive; ACT is incompatible with it and should be removed from this endpoint.

---

POST /chunks — remove ACT

1. Data is never encrypted. Raw chunks are content-addressed plaintext. ACT wraps only the content-hash reference, not the data — unlike the BZZ pipeline where the payload is actually encrypted before chunking.
2. Wrong abstraction layer. The chunk endpoint exists for atomic, low-level chunk operations — used by tooling that manages chunk-level storage directly. It does not expose file-level semantics like the BZZ or bytes endpoints do. ACT is a file-access-control feature and does not belong at this layer.

---

Proposal:

• Remove Swarm-Act / Swarm-Act-History-Address header support from POST /soc/{owner}/{id} and POST /chunks.
• ACT should remain only on upload paths where the pipeline performs actual payload encryption: BZZ, bytes, and file/collection endpoints.

---