[Refactor] Consolidate modules: merge zeroj-ceremony into zeroj-tools, and zeroj-patterns into zeroj-cardano

[satran004]

Context & Motivation

To reduce top-level module fragmentation:

1. zeroj-ceremony is a single Picocli CLI class (CeremonyCli.java) wrapping zeroj-tools. Merging it directly into zeroj-tools eliminates an unnecessary module boundary.
2. zeroj-patterns contains only 5 small helper classes (MembershipProof, StateTransition, etc.) closely tied to Cardano L1 anchoring. Merging it into zeroj-cardano simplifies downstream dependencies.

Scope & Tasks

• Move CeremonyCli into zeroj-tools (e.g. com.bloxbean.cardano.zeroj.tools.cli.CeremonyCli).
• Move pattern classes from zeroj-patterns into zeroj-cardano (e.g. com.bloxbean.cardano.zeroj.cardano.patterns).
• Remove zeroj-ceremony and zeroj-patterns from settings.gradle and BOMs.
• Update POMs and documentation.

Risk Classification

• R1: Module structure & API refactor.
• Reference: docs/zeroj-comprehensive-review-and-readiness-gemini.md (Section 3.2).

[satran004]

Closing — one half conflicts with #24, and the stated motivation for that half is factually wrong.

zeroj-patterns — conflicts with #24, in the opposite direction. This issue proposes merging it into zeroj-cardano. #24 proposes moving it out to a use-cases/reference project, on the grounds that it "contains application-level membership, nullifier, credential, range, and state patterns rather than cryptographic foundations." Both cannot happen; that call belongs in #24.

The motivation given here also does not hold: zeroj-patterns is not "only 5 small classes". It is 14 main classes / 1,221 main LOC (1,737 including tests), and includes a policy layer — PatternPolicies, VerificationPolicyTemplate — alongside the membership, nullifier and state-transition families:

PatternPolicies, VerificationPolicyTemplate,
StateTransition, StateTransitionInput, StateTransitionResult, StateTransitionVerifier,
NullifierClaim, NullifierClaimInput, NullifierClaimVerifier, ClaimResult,
MembershipProof, MembershipInput, MembershipResult, MembershipVerifier

That is a large enough surface that "fold it in, it's only 5 classes" is the wrong frame for the decision.

zeroj-ceremony → zeroj-tools — this part is accurate and worth keeping. zeroj-ceremony really is a single main class (CeremonyCli.java) wrapping zeroj-tools, which currently has no CLI at all (three library classes: ZkeyContributor, SnarkjsHashToG2, ChaChaRng, no picocli). Worth doing.

Note it must be sequenced with #39, which proposes adding a different new CLI to zeroj-tools — both touch the same surface.

Suggest reopening the zeroj-ceremony half as its own small ticket if wanted, and settling zeroj-patterns under #24.