Add has_operator() boolean read as a cheaper alternative to fetching the full operator address

[Jagadeeshftw]

📌 Description

operator() returns Result<Address, Error>, erroring when no operator is currently appointed, per the README. A caller (e.g. the frontend, or an admin dashboard) that only wants to conditionally render "operator appointed / not appointed" UI has to catch/handle the error case just to answer a yes/no question, when a plain boolean read would be cheaper and simpler to consume.

🧩 Requirements and context

• Add has_operator(env) -> bool, returning whether an operator is currently appointed, without requiring the caller to handle operator()'s error path.
• No change to operator()'s existing behavior or error contract.
• Update the README's Admin & lifecycle table.

🛠️ Suggested execution

• Add the new pub fn to src/lib.rs, backed by the same underlying storage check operator() uses.
• Add tests in src/test.rs for both the appointed and unappointed states.
• Update the README.

✅ Acceptance criteria

• has_operator() correctly reflects whether an operator is currently appointed.
• operator()'s existing behavior is unchanged.
• Documented in the README.

🔒 Security notes

Read-only addition; no new attack surface.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[GBOYEE]

Hi maintainers, I can handle this one. I'll implement it to spec and add tests. I'll open a PR referencing this shortly once assigned.

[Binali223]

Hello Maintainer, I'd like to work on this issue. I have experience with blockchain development and state management, and I can implement this. Please consider assigning it to me.