setec: consider whether write/delete access should imply metadata (info) permission

Currently (March 2026), the [setec API](https://github.com/tailscale/setec/blob/main/docs/api.md) maps access permissions directly to API operations. This means, for example, that the ability to `get` a secret's value does not imply the ability to read its metadata (`info`), or vice versa.

While this clean separation is nice conceptually, it can sometimes complicate operations: For example, clients that want to administer secrets (`put`, `activate`, and delete operations) usually also want the ability to see metadata, but as the API stands they would need to be explicitly granted `info` in addition to those other rights.

Perhaps instead, we should say that being granted operation types that allow mutation of secret data (`'put`, `create-version`, `delete`, `delete-version`, and possibly `activate`) should _imply_ the `info` permission, even if it is not explicitly spelled out in the policy.