Contract size, feature set and modular dispatch proxies

In the future, we will move FWSS code into a [Modular Dispatch Proxies](https://eips.ethereum.org/EIPS/eip-8167) pattern because of contract size limitations. As things stand now, FWSS cannot accept more features without extracting things from the core code.
We should investigate which parts of the FWSS contract are clearly separable so we can use that pattern in the future.

Additionally, this ties into the evolution of PDP architecture to allow more services to operate separately in the PDP dataset lifecycle.
Ideally, FilBeam, for example, would be a separate service that the client can enable but doesn't live in the FWSS contract itself, but that is a part of wider work.

Start by locating the FWSS contract and documenting its current feature set and contract-size constraints. Map which FWSS responsibilities are separable and how they relate to the PDP dataset lifecycle, including the possible FilBeam service boundary. Done means producing an agreed inventory of modular candidates and their architectural relationships.

Written by the indexing model from the issue text.