Feat: Programmable ACLs support

I have taken on productisation of PR #536 - Programmable ACLs support.

This Issue covers the full suite of decisions and actions needed across the Filecoin Universe to land this feature at production quality. It does not recreate all the detailed information and discussion around it. For that, review the [original PR](https://github.com/FilOzone/filecoin-services/pull/536), the [Notion design page](https://app.notion.com/p/filecoindev/202607-Optional-dataset-level-programmable-Authorizers-397dc41950c1809295ddc3d6ff6669b0), and the [gas discussion](https://app.notion.com/p/filecoindev/Pricing-GA-Fast-Follow-39ddc41950c180fc9b11ce2871a10f88).

## Scope

### Services

This feature is limited to **FWSS only**: although it touches Curio and could relatively easily expand to other developer surfaces we will not put any effort into those (eg Storage Manager, Filecoin Pin, raw Synapse).

That said, I would strongly consider reusing it for other services where access control is an unmet requirement, such as any retrieval market.

### Legacy auth

We do not plan to remove the legacy Session Key Registry: if the Authorizer contract is unset then existing SKR functionality survives.

## Impact

Adding this feature brings great benefits and an essential feature to FWSS: no sensible operator - Enterprise or solo dev - will embrace storage without a notion of access control. Having programmable, per-dataset control is a real step forwards and a table-stakes feature that makes sense to invest in ahead of tested customer demand (although we also do have customer demand too, which is nice).

The downside to this feature is that it adds a lot of gas cost to FWSS operations which need to be swallowed in the SP's operation cost. I believe the impact has been evulated and considered _just about_ acceptable, but if this feature gains significant traction we should look at optimising it. Note that the feature itself (the extension point to allow programmable access control) doesn't add much gas at all: it's the user's access control Authorizer contract that does that.

## Gating decisions

1. Gas cost: the initial Authorizer contract we expect to launch with is a P256 WebAuthn Passkey verifier. Very cool, very compelling, very expensive. Adds 100M gas. PR #536 does include a total gas cap but it's high.
2. Given that we have a gas cap, do we need to have some kind of whitelist registry of Authorizers or can we leave it as designed, a free-for-all where clients can either deploy supplied standard ones _or_ write their own? Griefing is capped and our own use cases effectively max it out already. But other safety issues, DOS etc are real.

## Full suite of PRs

This feature requires several PRs to land properly. This is an all-or-nothing set: if we decide to reject 536 then we abandon all of them.

* The main one: #536
* A small housekeeping one: #560
* Curio companion to 560: https://github.com/filecoin-project/curio/pull/1391
* Curio implementation of optional Authorizer allowList: https://github.com/filecoin-project/curio/pull/1446
* Initial sample Authorizer contracts: https://github.com/FilOzone/filecoin-services/pull/587
* Dev docs: https://github.com/FilOzone/synapse-sdk/pull/905

Start by reviewing PR #536 and the linked Notion design and gas discussion to understand the proposed programmable ACLs. Then compare the listed companion PRs across filecoin-services, Curio, and synapse-sdk; done means the all-or-nothing FWSS feature suite and its gating decisions are resolved.

Written by the indexing model from the issue text.