Add policy decision layer for agent actions

Description

The pitch.

## Problem

NANDA Town has layers for identity, auth, privacy, payments, trust, memory, coordination, and failure detection, but it does not yet have a small deterministic policy decision point for agent actions.

Before an agent publishes data, spends credits, calls an external tool, or changes authority, it should be able to ask: is this action permitted, denied, or does it need approval?

This PR adds that missing policy layer.

## What is in the diff

| Path | Purpose |
| --- | --- |
| `packages/nest-core/nest_core/layers/policy.py` | New `Policy` Protocol plus `PolicyRequest`, `PolicyDecision`, and `PolicyEffect`. |
| `packages/nest-plugins-reference/nest_plugins_reference/policy/strict.py` | Reference deny-by-default policy. Permits safe public reads, denies sensitive public exports, requires approval for high-value payments, and denies unknown actions. |
| `packages/nest-plugins-reference/nest_plugins_reference/policy/allow_all.py` | Unsafe baseline plugin used as the foil. |
| `packages/nest-core/nest_core/scenarios_builtin/policy_guard.py` | Deterministic adversarial scenario that exercises safe, sensitive, high-value, and unknown actions. |
| `scenarios/policy_guard.yaml` | Runnable scenario config. |
| `packages/nest-core/nest_core/validators.py` | Four policy validators registered under `policy_guard`. |
| `packages/nest-plugins-reference/tests/test_policy.py` | Unit, integration, adversarial, and determinism tests. |
| `docs/layers/policy.md` | Documentation and usage notes. |

## Why this is useful

It fills a practical security gap. Auth answers “who are you?” Privacy answers “who can read this?” Payments answer “can value move?” A policy layer answers “should this agent be allowed to do this action right now?”

It is intentionally small and composable. The layer does not execute actions or replace other layers. It only returns a replayable decision that other layers or agents can respect.

It is testable, not just illustrative. The `strict_rules` plugin passes the scenario validators. The `allow_all` baseline fails the restrictive checks, proving the validators catch unsafe behavior instead of merely checking that messages exist.

## Verification

Ran the full local CI gate:

```bash
make ci-local