Refactor vault-role access control to flexible @CheckAccess annotation

## Context

As the emergency access feature evolves (PR #390), the permission system is becoming increasingly complex. The current `@VaultRole` annotation with additional flags like `bypassForEmergencyAccess` is not flexible enough to handle the various authorization scenarios cleanly.

## Current Approach

Currently, authorization is handled via `@VaultRole` annotation with various parameters:

```java
@VaultRole(value = {OWNER}, bypassForEmergencyAccess = true)
```

This approach requires adding new boolean flags for each new authorization bypass scenario, which doesn't scale well.

## Proposed Solution

Introduce a new `@CheckAccess` annotation that supports flexible composition of multiple access checks with logical AND/OR semantics:

```java
@CheckAccess(
any = {
@AccessCheck(kind = AccessCheck.Kind.REALM_ROLE, value = "admin"),
@AccessCheck(kind = AccessCheck.Kind.IS_RECOVERY_COUNCIL_MEMBER, value = "true")
},
all = {
@AccessCheck(kind = AccessCheck.Kind.VAULT_ROLE, value = "member")
}
)
```

This pattern would allow:
- Multiple types of access checks (realm role, vault role, recovery council membership, etc.)
- Logical combinations: `any` (OR) and `all` (AND) semantics
- Better extensibility for future authorization requirements
- Clearer intent in the code

## Implementation Considerations

1. Define `AccessCheck.Kind` enum with all supported check types
2. Implement a new filter/interceptor to process the `@CheckAccess` annotation
3. Support existing authorization patterns during migration
4. Migrate existing `@VaultRole` usages incrementally
5. Consider backward compatibility or deprecation path

## References

- PR #390: Emergency Access implementation
- Comment: https://github.com/cryptomator/hub/pull/390#discussion_r2769429731
- Related file: `backend/src/main/java/org/cryptomator/hub/api/EmergencyAccessResource.java`