Feat/registry campaign enumeration 151

[nasarajoe]

Summary

Makes the registry answer "what campaigns exist?" on-chain. DataKey::FarmerCount and
DataKey::CampaignCount were declared but never read or written anywhere in the crate —
they are now actually populated, backed by a sequential index that supports paginated
enumeration of both campaigns and farmers.

This removes the need for the event-log scanning workaround in
client/src/hooks/useAdminCampaigns.ts, which silently drops campaigns created before the
lookback window or before whatever history the configured RPC provider retains.

New contract methods

Method	Returns	Notes
get_campaign_count()	u64	Total campaigns known to the registry
get_campaign_ids(offset, limit)	Vec<u64>	Registration order; limit clamped to 100
get_farmer_count()	u64	Total registered farmers
get_farmers(offset, limit)	Vec<Address>	Registration order; limit clamped to 100

Semantics: ids come back in registration order with stable indices; an offset at or past
the count returns an empty vector (the termination signal when paging); a limit above 100
is clamped rather than rejected, so a short page does not by itself mean end-of-list.

Changes

File	Change
registry/src/types.rs	Added CampaignIndex(u64), CampaignIndexed(u64), FarmerIndex(u64)
registry/src/storage.rs	Index writers, paginated readers, MAX_PAGE_LIMIT = 100
registry/src/campaign.rs	Indexes in both register_campaign and link_campaign_escrow
registry/src/farmer.rs	Indexes in register_farmer
registry/src/lib.rs	Exposes the four new getters
registry/src/test.rs	11 new tests
INTEGRATION.md	New "Campaign & Farmer Discovery" section

Design notes

Per-index storage keys, not one append-only Vec<u64>. The issue flagged the
unbounded-growth concern from Issue 9. A single Vec in one storage entry means every
registration rewrites an ever-larger blob and eventually hits entry size limits.
CampaignIndex(u64) -> u64 keeps each write constant-cost regardless of registry size.

Both entry points index, counted once. The issue suggested incrementing in
register_campaign "and/or link_campaign_escrow". Neither alone is sufficient:
link_campaign_escrow does not require prior registration, so indexing only in
register_campaign would leave linked-but-unregistered campaigns invisible — precisely the
gap being closed. Both index, and a CampaignIndexed(u64) marker makes index_campaign
idempotent so a campaign travelling both paths is counted exactly once.

Acceptance criteria

• Full set of campaign ids retrievable, paginated, without event-log scanning
• CampaignCount/FarmerCount populated and accurate
• INTEGRATION.md documents discovery as the recommended path over event scanning

Verification

• 52/52 registry tests pass, including all 11 new ones.
• WASM release build succeeds (wasm32-unknown-unknown, exit 0) — deployable, not merely
  test-passing.

Pre-existing failure (not from this PR)

cargo test --workspace fails to compile production_escrow (E0308, E0277 on
i128 * i64). Untouched crate, no dependency edge to registry, byte-identical errors
with these changes stashed. Workspace CI is red independently of this work.

Follow-up

client/src/hooks/useAdminCampaigns.ts can now drop its bounded-lookback event scan.
Left out to keep the contract change reviewable on its own.

Closes #151