docs(registry): fix method name is_human_bool

contracts/registry/README.md

@@ -43,7 +43,7 @@ The IAH Registry supports the following extra queries, which are not part of the
 - `is_human(account: AccountId) -> Proof`, where proof is list of SBTs (represented as a list of issuers and issuer minted tokens). The registry has a property `iah_sbts` that specifies which tokens from which issuers are required from an account to be considered a human. In case the account is missing any of the required tokens, or is considered a fake account (through the registry `blacklist`) an empty proof will be returned (empty list).
   For example, if `alice` is a human because she has `fractal: class 1` token with `tokenID=24`, then the function returns `["<fractal issuer account>", [24]]`. If the account is not a human, then an empty proof is returned (empty list). If the `iah_sbts` property contains more tokens, for example `fratcal: [1,2]` the `is_human` will return the proof with the tokens only if the account has both of the SBTs. Otherwise an empty proof will be returned. Eg: for `alice` with two tokens `class=1, tokenID=24` and `class=2, tokenID=40` the method will return `["<fractal issuer account>", [24, 40]]`. for `bob` with one token `class=1, tokenID=26` the method will return an empty list.
 
-- `is_human_beta(account: AccountId) -> bool`: similar to `is_human`, but returns `true` if an account is considered human, and `false` otherwise. We DO NOT RECOMMEND using this function. You SHOULD use `is_human` instead. Returning bool may create wrong practices. Humanity will be a metric, not a true/false. Each "client" should have his own criteria and asses the humanity proof (e.g. check for KYC SBTs, liveness, ...). 
+- `is_human_bool(account: AccountId) -> bool`: similar to `is_human`, but returns `true` if an account is considered human, and `false` otherwise. We DO NOT RECOMMEND using this function. You SHOULD use `is_human` instead. Returning bool may create wrong practices. Humanity will be a metric, not a true/false. Each "client" should have his own criteria and asses the humanity proof (e.g. check for KYC SBTs, liveness, ...). 
   Moreover, for some transactions it is critical to record the proof or acquire a lock (using `is_human_call_lock`) to protect from repeating action by the same human. Example scenario: consider Alice uses her humanity proof to vote, then she transfers her "soul" to another account, and votes again.
 
 - `account_flagged(account: AccountId) -> Option<AccountFlag>` - returns account status if it was flagged. Returns None if the account was not flagged. More context about account flagging is specified in the [IAH Flag Accounts](https://near-ndc.notion.site/IAH-Flag-Accounts-b5b9c2ff72d14328834e2a0effa22938?pvs=4).