P0c cleanup: remove backward-compat no-attachment guardrail fallback once CP rolls out

Context

PR #411 added a backward-compat path in crates/aisix-guardrails/src/build.rs (build_index_from_snapshot): any guardrail definition with zero attachment rows is applied as an implicit env-scope entry at priority 0, preserving the pre-P0c "apply globally" behavior during the rolling-upgrade window.

This path exists to bridge the gap between the DP being deployed (P0c) and the CP (AISIX-Cloud #516) writing guardrail_attachment rows for all existing guardrails.

When to remove

Remove the // Backward compat block in build_index_from_snapshot once:

1. AISIX-Cloud PR #516 (marshalGuardrailKV P0c projection) is merged and deployed.
2. The CP is confirmed to write at least one attachment row for every guardrail on creation/update.
3. Any existing environment has been migrated (backfill or re-save of existing guardrail rows).

After removal, a guardrail with zero attachment rows is a silent no-op — operators must explicitly attach it to a scope.

Risk of not removing

If left indefinitely, the fallback silently widens scope for any future guardrail row created without an attachment (operator error, migration bug, test fixture). The tracing::info! log in the fallback path surfaces the condition, but the behavior is unintuitive after the P0c attachment model is fully adopted.

File to edit

crates/aisix-guardrails/src/build.rs — the // TODO(P0c-cleanup) comment in build_index_from_snapshot.

Check the rollout status of AISIX-Cloud PR #516 and confirm that existing environments are migrated and every guardrail creation or update writes an attachment row. Then inspect the // TODO(P0c-cleanup) block in crates/aisix-guardrails/src/build.rs, within build_index_from_snapshot. Done means the backward-compat fallback is removed only after those conditions are confirmed.