hive-c0re: fast-forward applied/<name>/main too, not just the one-shot relock

argus + mara (PR #4339 review): the previous commit's per-agent lock
relock is a one-shot effect on the single rebuild the cascade triggers
- applied/<name> never moves, so the next relock=true rebuild trigger
(the boot sweep, most notably) re-locks against applied/<name> and
reverts straight back to whatever it was stuck on. The fix didn't
outlive the transaction it ran in.

New forge::fast_forward_applied_main(name), sibling to the existing
reseed-only fetch_config_main_into_applied: for an applied repo that
already has a .git and just needs to catch up, force-set rather than
fast-forward-gated since there's no PR to review on this path either.
Called per cascade agent right after the relock, best-effort so one
unreachable agent repo doesn't block the others.

Once applied/<name>/main has actually moved, lock_update_for_rebuild's
override (always reads current applied/<name>/main, no ?rev pin)
naturally stays in sync on any later relock=true rebuild instead of
reverting.

hive-c0re/src/forge/mod.rs

@@ -18,8 +18,8 @@ pub use pr_merge::{
 pub use reconcile::{reconcile_config_apply, reconcile_config_status};
 pub use repos::{
     clone_config_into_proposed, create_agent_repo, ensure_config_repo, ensure_knowledge_repo,
-    ensure_meta_remote, ensure_repo, ensure_shared_docs_repo, fetch_config_main_into_applied,
-    meta_read_access, push_config, push_meta, shared_docs_access,
+    ensure_meta_remote, ensure_repo, ensure_shared_docs_repo, fast_forward_applied_main,
+    fetch_config_main_into_applied, meta_read_access, push_config, push_meta, shared_docs_access,
 };
 pub use users::{core_token, ensure_user_for, provision_user_token};