Security rule `action = "ask"` has no resolution path

## Summary

`action = "ask"` compiles, evaluates, and enforces, but nothing can ever resolve
an ask. In practice `ask` behaves as `block` with a different message.

## What works

- `emit_matching_security_rules_with_decision` writes a `pending` row to
`security_ask_events` and returns the `ask_id` on the enforcement decision.
- `SecurityEnforcementDecision::with_ask_resolution` correctly maps
approved -> allow and denied -> block.
- The file, process, and evaluate-route rails all reach that code.

## What is missing

1. **No resolver.** `emit_security_ask_resolution` and
`emit_security_ask_resolution_blocking` have no production callers -- only
tests. There is no service route, CLI command, or UI affordance that moves a
pending ask to approved or denied, and nothing polls for one.

2. **The network boundary never creates one.** `evaluate_security_boundary` is
what the MITM proxy and DNS server call, and it does not emit a pending ask
at all: `enforcement.ask_id` stays `None`. An `ask` rule on
`http.*` / `model.*` / `mcp.*` / `dns.*` returns 403 with
"requires approval by security rule: " and leaves nothing on the ledger
for anyone to approve.

So the file and process rails leave an unanswerable pending row, and the
network rail leaves no row at all.

## Impact

A profile author writing `action = "ask"` gets a hard denial. That is
fail-closed, so it is not a security hole -- but it is not the documented
behavior. `docs/src/content/docs/security/policy.md` says ask means
"Pause materialization until an approval or denial is recorded", and no
approval or denial can be recorded.

## Suggested scope

- A service route to list pending asks and resolve one, on the logger DB
boundary (`capsem-logger` owns the query execution).
- `evaluate_security_boundary` emitting a pending ask so the network rail has
something to resolve, with the request held or failed pending the answer.
- A UI/CLI surface to answer.
- Until then, either document ask as "deny and record for review" or reject it
at rule compilation.

Found during a security-invariant review of the rule spine.

Start with docs/src/content/docs/security/policy.md and trace emit_matching_security_rules_with_decision, emit_security_ask_resolution, emit_security_ask_resolution_blocking, and evaluate_security_boundary. The listed scope spans the logger database boundary, network rail, and UI/CLI surfaces; done means pending asks can receive an approval or denial on every relevant rail, or the documented behavior is explicitly changed.

Written by the indexing model from the issue text.