Rework Submitter Concurrency

[mkysel]

Serialize submitter worker concurrency by adding db.AdvisoryLocker.LockSubmitterWorker and updating payerreport.SubmitterWorker.SubmitReports to require a per-report majority of (len(ActiveNodeIDs)/2)+1 attestations and mark reports Submitted

This change introduces a submitter-specific advisory lock and updates report submission to use a per-report majority threshold and explicit post-submission status updates. It adds a new SubmitterWorker advisory lock kind and corresponding locker methods, modifies the submitter worker to acquire the lock during processing, and updates submission logic to compute required attestations from ActiveNodeIDs and set the report status to Submitted after successful on-chain submission.

• Add SubmitterWorker lock kind and implement db.AdvisoryLocker.LockSubmitterWorker and db.TransactionScopedAdvisoryLocker.LockSubmitterWorker in advisory_lock.go
• Update payerreport.SubmitterWorker.SubmitReports to acquire a transaction-scoped advisory lock, evaluate per-report majority (len(ActiveNodeIDs)/2)+1, skip insufficiently attested reports, and call payerReportStore.SetReportSubmitted after successful submission in submitter.go
• Add comments clarifying submission status handling in payer_report_manager_storer.go and generator.go

📍Where to Start

Start with the submission flow in payerreport.SubmitterWorker.SubmitReports in submitter.go, then review the advisory lock additions in advisory_lock.go to understand how the transaction-scoped lock is acquired and released.

Changes since #1219 opened

• Replaced comment documentation for concurrency timing hazard [d78190f]

---

Macroscope summarized 3f84733.

[mkysel]

to be addressed in a 3rd PR.