[Backend] Add a contract blueprint deprecation and ownership model

[grantfox-oss]

Problem

As a community-maintained registry grows, blueprints will inevitably become stale (contract upgraded, original author unreachable) or contested (two contributors submit conflicting interpretations of the same contract's events). There's currently no described mechanism for who can update an existing blueprint, how staleness is flagged, or how conflicts are resolved — this becomes a real governance gap as the registry scales past a handful of contracts.
Proposed work

Add an owner/maintainers field (GitHub usernames) and status field (active, needs-review, deprecated) to the blueprint schema (building on the versioning from Issue #23).
Define a lightweight policy in CONTRIBUTING.md: how a non-owner proposes a correction, how staleness gets flagged (tying into the fixture-drift detection from Issue #29), and a timeout after which an unresponsive owner's blueprint can be taken over.
Surface blueprint status/ownership in the dashboard provenance badge from Issue #27.

Acceptance criteria

Schema supports ownership/status without breaking existing blueprints (sensible defaults for missing fields).
Policy document covers at least: correction proposal, staleness flagging, unresponsive-owner handoff.
At least one real existing blueprint is updated to use the new fields as a working example.

[Ebenezer199914]

can i work on this issue

[modrispath]

I'd like to work on this.

The governance gap here is real — a registry without clear ownership and deprecation rules ends up with stale blueprints that nobody feels empowered to fix and conflicts that stall silently.

I'll extend the blueprint schema with an optional maintainers array (GitHub usernames) and a status field defaulting to active for existing blueprints so nothing breaks. The three valid statuses will be active, needs-review, and deprecated, with sensible defaults covering the missing-field case.

The policy document in CONTRIBUTING.md will cover three scenarios: how a non-owner proposes a correction (PR with explanation, original maintainer gets a review window), how staleness gets flagged (tying into the fixture-drift detection from #29 as the trigger for needs-review), and the unresponsive-owner handoff timeout (a defined number of days with no response before the community can take over maintainership via PR).

I'll update at least one existing blueprint with the new fields as a concrete working example, and surface the status and ownership in the provenance badge from #27 so the dashboard reflects current blueprint health at a glance.

Ready to start if assigned.

[AbuJulaybeeb]

Hi Maintainer, haven reviewed the description of the issue, and well experienced with Js Library,
I would like to hop on the issue and sure to deliver at ETA 2hrs

[grantfox-oss]

🦊 GrantFox — @modrispath has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #253)
2. Your PR will be reviewed by the Open-audit-foundation maintainers

Good luck! Track your progress on GrantFox.

[modrispath]

Thank you for giving me the opportunity! I'm already working on it.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@modrispath's PR #256 was approved and merged by @Osuochasam.

🏆 @modrispath: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (223 total points). Track your full progress on GrantFox.

👏 Great work, @modrispath! Keep contributing to Open-audit-foundation.