Support nested claim paths in policy conditions

[arber-salihi]

Summary

Adds support for referencing nested token claims in policy conditions via dot-notation. A condition's field (and central required_claims/forbidden_claims) may now address a claim inside a nested object:

conditions:
  - field: "app_metadata.preferences.theme"
    pattern: "^dark$"

For a token containing {"app_metadata": {"preferences": {"theme": "dark"}}}, this matches against dark.
(In real life, you probably don't want to authorize callers against such claims, though...)

NOTES
A literal top-level key takes precedence over path traversal.
As such, existing flat claims (repository, ref, sub, etc.) are completely unaffected.

Testing

• Unit tests (provider_test.go): top-level, nested, deeply-nested, missing keys, descending past a leaf, non-string leaves (bool/array), and literal-key precedence.
• Integration test + fixture (nested_claim.tpl.yaml) exercising a nested-path match end-to-end.
• go build, go vet, and gofmt clean.