`scripts/interact.sh`'s `kora_add_verifier` (and the `demo.sh` reference flow) calls the pre-staking 2-argument `risk_registry.add_verifier` instead of the required `(admin, verifier, stake_amount)` signature

[OxDev-max]

Description

scripts/interact.sh:93-96:

kora_add_verifier() {
  # $1 = admin, $2 = verifier_address
  _invoke "$RISK_REGISTRY" add_verifier --admin "$1" --verifier "$2"
}

But risk_registry::add_verifier (contracts/risk_registry/src/lib.rs:142) is
add_verifier(env, admin, verifier, stake_amount), and its body performs a real
token_client.transfer(&verifier, &env.current_contract_address(), &stake_amount) — a
mandatory token stake, not an optional parameter. scripts/demo.sh, described in its own header
comment as "the canonical first script a new contributor should run," sources interact.sh and
depends on kora_register_sme succeeding, which in turn requires a verifier that was
successfully added via kora_add_verifier — so the repo's own reference onboarding flow is
currently broken by this same staking-model migration (issue #262) that also broke the
integration test harness (issue #2) and deploy.sh (issue #7).

Requirements and Context

This is the third independent place (after the integration harness and deploy.sh) where the
verifier-staking feature shipped without its callers being updated — establishing a clear,
fixable pattern of interface drift across the whole "operate the protocol" tooling surface, not
just the test suite.

Suggested Execution

1. git checkout -b fix/interact-sh-add-verifier-staking
2. Update kora_add_verifier in scripts/interact.sh to accept and forward a stake_amount
   argument: kora_add_verifier() { _invoke "$RISK_REGISTRY" add_verifier --admin "$1" --verifier "$2" --stake_amount "$3"; }.
3. Update scripts/demo.sh's call site(s) to supply a stake amount (e.g. a new
   VERIFIER_STAKE_AMOUNT env var with a sensible default), including any token-minting/
   approval steps the staking token requires before the verifier can stake.
4. Audit scripts/interact.sh for any other helper functions whose underlying contract
   function has gained new required parameters since the helper was written (e.g. compare
   kora_register_sme, kora_mint_invoice, kora_list_invoice, kora_fund_invoice,
   kora_repay against their contracts' current signatures) and fix any further drift found.
5. Run scripts/demo.sh end-to-end against a local sandbox/testnet and confirm the full
   mint→list→fund→repay→yield flow completes without error.

Acceptance Criteria

• kora_add_verifier in interact.sh supplies a stake_amount matching the contract's real signature
• demo.sh successfully stakes and registers a verifier as part of its walkthrough
• Every other kora_* helper in interact.sh is confirmed (via direct signature comparison) to match its target contract's current entrypoint
• demo.sh runs to completion end-to-end against a live/sandbox deployment

Guidelines: PR description must include Closes #<issue-number>.
Complexity: High (200 points)