Implement the Proof of Resource protocol

[flo2517]

Prove that a provider actually holds the CPU, RAM, and GPU it advertises, through bounded cryptographic challenges rather than trust in its self-reported inventory. Today agent-inventory reports hardware via sysinfo and nothing verifies it; Proof of Resource closes the gap between advertised and real capacity, which is the precondition for a market where over-advertising is not free.

No new ADR gate is required — ADR-012 §6 records this explicitly. This issue extends the existing challenge model of ADR-007 and the evidence-summary model of ADR-011 §3; it adds no new trust boundary. It does require a protocol/proto change with full consumer analysis per AGENTS.md.

Acceptance criteria:

• challenges reuse the existing nonce and block-number deadline pattern (Challenge { expected_response, deadline } in blockchain/pallets/availability/src/lib.rs), and are rejected after the deadline the same way ChallengeTimeout already works — no second replay scheme is introduced;
• SolveChallengeRequest.Type in protocol/proto/openinfra/agent/v1/agent.proto is extended with the new dimensions, consumers are identified, wire compatibility is preserved, buf breaking-change checks pass, and both languages are regenerated;
• challenges are bounded in CPU, memory, and wall-clock cost so they cannot be used to starve a provider's paying workloads, and a provider may not be challenged more often than a stated rate;
• results are hard to forge and hard to outsource: passing must require actually holding the resource, not proxying to a faster machine;
• evidence lands on-chain only as a bounded integer summary plus payload_hash, per ADR-011 §3 — never the raw payload;
• GPU is treated as a distinct resource class with its own advertisement and verification, not folded into CPU;
• a provider that fails or refuses a challenge has that outcome recorded and reflected in its reputation vector, with degraded quorum reported honestly rather than as success;
• tests cover a passing proof, a forged result, a replayed result, a late result, an outsourced/proxied attempt, a provider under full paying load, and a challenge for a resource class the provider never advertised.

---

Original request (FR, preserved verbatim):

Implémenter des challenges cryptographiques pour prouver la présence réelle de CPU, RAM et GPU.