Fix DAG named "DAGs" colliding with the global DAGs permission resource

[potiuk]

What

resource_name() returned the dag_id unchanged when it equalled a reserved resource name. Because a real dag_id can be DAGs (it passes the dag_id validator), a DAG named DAGs resolved to the global DAGs permission resource instead of its own per-DAG DAG:DAGs resource, so that DAG's permissions were applied to the wrong resource.

This drops the reserved-name short-circuit so a dag_id is always prefixed (DAG:<dag_id>). The already-prefixed branch (DAG:foo, DAG Run:foo) still short-circuits — safe because those prefixes contain a colon, which the dag_id validator (KEY_REGEX = ^[\w.-]+$) forbids, so no real dag_id can reach it. The same fix is mirrored in the duplicated airflow-core copy.

Tests

• resource_name("DAGs", RESOURCE_DAG) now returns DAG:DAGs (FAB + core copies); ordinary and already-prefixed names unchanged
• full providers/fab test_security.py suite passes; ruff clean

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.8

Generated-by: Claude Opus 4.8 following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[potiuk]

@vincbeck — one judgement call to flag here: I removed the if dag_id in RESOURCE_DETAILS_MAP.keys(): return dag_id short-circuit in resource_name(). I couldn't find a call site that legitimately relies on passing a bare reserved resource name (DAGs / DAG Runs) as the dag_id arg — every caller passes a real dag_id, and the global-resource auth check is done separately — so removing it looks safe. But you've been in this code recently; if there was an intended use for that mapping that I'm missing, say so and I'll rework it. (I kept the already-prefixed DAG: branch, which is clearly load-bearing for idempotency.)