Add Ved Patel's midterm blog post for SoB 2026

[Vedd-Patel]

Midterm Blog Post: Floresta Error Handling

This PR adds my midterm blog post for Summer of Bitcoin 2026.

Changes Included:

• Added my author profile to _config.yml
• Created new post: 2026-06-30-making-floresta-crash-proof-a-systematic-error-handling-overhaul.md
• Uploaded custom featured image to assets/images/blog_content/

The post details my work on replacing crash-prone .unwrap() and .expect() calls with a typed, recoverable error model in the Floresta Bitcoin node.

[adi-shankara]

@Vedd-Patel Thanks for the detailed Floresta article. Before publication, please correct these technical-accuracy issues:

• The article says the workspace lints are set to deny and that future unwrap() usage will cause a compiler error. The currently linked Floresta PR #1144 sets unwrap_used, expect_used, panic, indexing_slicing, and arithmetic_side_effects to warn. Please update the table and surrounding explanation to match the actual patch, or update the linked implementation first if deny is the intended final state.
• The statement that unwrap() gives “No error message” is inaccurate: a Rust panic normally emits a panic message. Please distinguish an uncontrolled panic from typed, recoverable error handling.
• Please review the opening claim that such a crash could directly mean a corrupted database or a missed double-spend; this overstates what follows from an unwrap() panic unless you provide a precise, sourced failure path.
• The cited implementation PRs #1075, #1133, and #1144 are currently open, so please avoid wording that presents unmerged work as already landed.

These changes fall under the README’s Technical Content Standards and Technical Accuracy requirements.

Once those are updated, please reply here and we’ll re-review the PR.

[Vedd-Patel]

@adi-shankara i've addressed the requested changes and amended them to the existing commit only
re-review whenever you have a chance!

[adi-shankara]

@Vedd-Patel Thanks for the update; the lint levels, panic wording, and open-PR wording now match the linked work. One remaining reliability claim needs qualification:

• The paragraph about a momentary disk hiccup says an unwrap() panic means the operator has to "restart, re-sync." A panic does require restart/recovery, but it does not by itself require a blockchain re-sync; that depends on whether persisted state was lost or corrupted. Please change this to "restart and recover" or qualify when a re-sync would actually be necessary.

This is covered by the README's Technical Accuracy requirement. Once updated, please reply here and we'll re-review.

[adi-shankara]

@Vedd-Patel Friendly follow-up: this branch has not received a new commit since the July 27 review. Please qualify the statement that an unwrap() panic necessarily requires a re-sync; "restart and recover" is accurate unless persisted state was lost or corrupted.

The PR is also now conflicting with master, so please rebase or merge the latest master and resolve the author-config conflict before replying for re-review.

[Vedd-Patel]

@adi-shankara i've made the changes and resolved the conflicts (rebased with master)
re-review whenever you've a moment!!