[Feature Request] Volume-level IP/network restrictions (volflag or accs syntax)

### Is your feature request related to a problem? Please describe.

Currently, copyparty supports restricting user accounts to specific IP ranges using the global `--ipr` option:

```
[global]
ipr: 192.168.0.0/24,127.0.0.1/32=lanuser
```

However, this is an **account-level** restriction. It would be very useful to have **volume-level** IP restrictions, where access to a specific volume is blocked based on the client's IP address, regardless of which account they're using.

### Describe the solution you'd like

I want to expose a config/admin volume that should only be accessible from my local network, while other volumes remain accessible from the internet. With account-level restrictions, if I want to give a user access to both volumes, I'd need to create separate user accounts or use workarounds.

**Desired syntax option 1 (using accs-style syntax):**

```
[/_Config]
/cfg
accs:
rwmda: lanuser
allow-ip: 127.0.0.1/32,192.168.0.0/24
```

**Desired syntax option 2 (as a volflag):**

```
[/_Config]
/cfg
accs:
rwmda: lanuser
flags:
ip-allow: 127.0.0.1/32,192.168.0.0/24
```

### Describe alternatives you've considered

- **Using `--ipr` at the account level**: This requires creating multiple accounts per user if they need different access patterns across volumes (e.g., `lanuser` for LAN-only volumes and `nasuser-internet` for public volumes). This creates a maintenance burden.
- **Reverse proxy with location-based IP filtering**: Adds complexity and an additional layer to maintain.
- **Firewall rules**: Less granular, affects entire server rather than specific volumes.

### Additional context

This would allow administrators to create security boundaries at the volume level based on network origin, which is particularly useful for:
- Admin/config volumes that should never be exposed to the internet
- Sensitive data that should only be accessible from trusted networks
- Multi-tier access architectures where some content is public and some is LAN-only

The current `--ipr` works well but operates at the wrong level of granularity for this use case.

Look at how the global `--ipr` option is implemented in the codebase, likely in a request handler or middleware. Then examine volume configuration parsing, possibly in volume flag handling. The goal is to add a new volume-level flag like `allow-ip` or `ip-allow` that checks client IP against a CIDR list before granting access to that volume. Test by creating a volume with the new flag and verifying access from allowed and disallowed IPs.

Written by the indexing model from the issue text.