feat: add pull-based attestation request workflow

[Mozez155]

closes #123

Subjects can now request attestations from registered issuers on-chain,
creating a pull-based flow instead of requiring issuers to know subjects
in advance.

New types (types.rs):

• AttestationRequest struct: id, subject, issuer, claim_type, timestamp,
  expires_at, status, rejection_reason
• RequestStatus enum: Pending / Fulfilled / Rejected
• ATTESTATION_REQUEST_TTL_SECS constant (7 days)

New error variants (errors.rs):

• RequestAlreadyProcessed, RequestExpired, DuplicateRequest

New storage keys + methods (storage.rs):

• AttestationRequest(String), IssuerRequests(Address)
• set/get_attestation_request, get/add_issuer_request

New events (events.rs):

• attestation_requested (req), request_fulfilled (req_ok),
  request_rejected (req_no)

New contract entry points (lib.rs):

• request_attestation — subject auth; deduplicates pending requests
• fulfill_request — issuer auth; creates standard attestation + audit log
• reject_request — issuer auth; stores reason, validates length
• get_pending_requests — paginated; filters expired/processed entries
• get_attestation_request — direct lookup by ID

21 tests covering the full lifecycle: happy paths, wrong-issuer, duplicate,
expiry, already-processed, reason-too-long, event emission, and pagination.

[drips-wave]

@Mozez155 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits