align(4909d): every rule arm that annotates reads one bar, kb_rule_threshold at 0.70

prompt_rule, pre_tool_rule and write_path_rule now share one settings key,
RULE_FLOOR_KEY = "kb_rule_threshold", default 0.70. The reply backstop keeps
its own 0.80, because there the floor is a stop bar. Moving the shared floor
through tune_retrieval or the Settings form records a tuning event on every
surface that reads it (set_dial, via retrieval_surfaces.sharing_floor), and
the result names the surfaces it carried as `moved_with`. Settings shows one
"Standing-rule confidence threshold" control where it showed three.

Operator ruling (2026-10-05): one shared bar for the rule arms, "especially
since we're only taking the first x number of them" -- the budget limits
what is shown; the bar only decides what is worth ranking. Kept a dial.

Why 0.70, from records read rather than percentiles:
- write_path_rule near-misses at 0.7199-0.72 were all false positives
  (rule 149 against a Lidarr comment, 157 against a retention Svelte file,
  121 against an Archives restore, 164 against a config test, 131 against a
  Go package), so the old 0.72 was not hiding real hits -- but the band does
  noise control on this arm, so dropping 0.02 costs little.
- prompt_rule: the operator set 0.70 by hand on 2026-09-18, after a 0.60
  experiment admitted junk and was reverted. 0.70 is the number with a human
  decision behind it.
- pre_tool_rule lines near 0.68 this session were mostly noise; rising to
  0.70 trims them, and the band still narrows what clears.

Retired keys: kb_promptrule_threshold, kb_toolrule_threshold and
kb_rulehint_threshold are no longer read. Rows an install stored under them
stay in the settings table, inert. On this instance the effective bars move
pre_tool_rule 0.68 -> 0.70, write_path_rule 0.72 -> 0.70, prompt_rule stays
0.70; record_release_defaults writes those per-surface release rows on boot,
so the telemetry shift has an event to explain it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

tests/test_write_path_trigger.py

@@ -485,13 +485,13 @@ async def test_writepath_threshold_is_operator_tunable_and_clamped():
 
 
 @pytest.mark.asyncio
-async def test_the_rule_arm_has_its_own_tunable_bar():
+async def test_the_rule_arms_have_their_own_tunable_bar():
     """Settable and clamped again, for the THIRD corpus.
 
     Separate from the code threshold above and separately settable, because the
-    two are measured against different things: 0.68 was derived from code
-    against note PROSE, and rules are short imperative technical
-    English — a more homogeneous corpus whose noise floor sits higher.
+    two are measured against different things: the code bar against note
+    PROSE, the rule bar against short imperative technical English — a more
+    homogeneous corpus whose noise floor sits higher.
     """
     from grimoire.services import plugin_context as pc
 
@@ -524,33 +524,28 @@ async def test_the_two_write_path_bars_are_independent():
 
 
 @pytest.mark.asyncio
-async def test_the_two_act_arms_read_independent_rule_bars():
-    """The command arm's bar moves without the write path's.
+async def test_both_act_arms_read_the_one_rule_bar():
+    """One stored value moves the command arm and the write arm together.
 
-    The two act arms behave like different subsystems at the same number,
-    because a code payload is long and rich where a shell command is short. A config assembler that
-    reads one key into both fields would silently undo that, and the symptom
-    would be invisible: both arms would simply agree again.
+    They search the same rules, and what limits each is its budget and band.
+    A config assembler that read a second key into either field would split
+    the bar again with nothing in the settings to show it.
     """
     from grimoire.services import plugin_context as pc
 
-    stored = {pc.RULEHINT_THRESHOLD_KEY: "0.75", pc.TOOLRULE_THRESHOLD_KEY: "0.61"}
+    assert pc.TOOLRULE_THRESHOLD_KEY == pc.RULEHINT_THRESHOLD_KEY
+    stored = {pc.RULEHINT_THRESHOLD_KEY: "0.61"}
     with _stored_settings(stored):
         cfg = await pc.get_writepath_config(1)
 
-    assert cfg["rule_threshold"] == 0.75
+    assert cfg["rule_threshold"] == 0.61
     assert cfg["tool_rule_threshold"] == 0.61
 
 
 @pytest.mark.asyncio
-async def test_a_garbage_command_bar_falls_back_to_its_own_default():
-    """Not to 0.0, and not to the write path's default.
-
-    Falling back to 0.0 would attach a rule to every Bash call in the session;
-    falling back to the sibling's default would quietly re-merge the two bars
-    that are kept separate, which is the harder failure to see because the arm
-    keeps working.
-    """
+async def test_a_garbage_rule_bar_falls_back_to_its_default():
+    """Not to 0.0, which would attach a rule to every Bash call and every
+    write in the session."""
     from grimoire.services import plugin_context as pc
 
     stored = {pc.TOOLRULE_THRESHOLD_KEY: "banana"}
@@ -558,20 +553,7 @@ async def test_a_garbage_command_bar_falls_back_to_its_own_default():
         cfg = await pc.get_writepath_config(1)
 
     assert cfg["tool_rule_threshold"] == pc.TOOLRULE_DEFAULT_THRESHOLD
-
-
-def test_the_command_bar_defaults_below_the_write_path_bar():
-    """A DIRECTION check, like its sibling above, and for the same reason: the
-    value is measured against one corpus, the relationship is not.
-
-    A shell command carries less text than a code payload and therefore scores
-    lower for the same relevance; at the write path's bar, consequential
-    commands retrieve nothing. Tuning either value stays free; inverting the
-    relationship would mute the command arm.
-    """
-    from grimoire.services import plugin_context as pc
-
-    assert pc.TOOLRULE_DEFAULT_THRESHOLD < pc.RULEHINT_DEFAULT_THRESHOLD
+    assert cfg["rule_threshold"] == pc.RULEHINT_DEFAULT_THRESHOLD
 
 
 def test_the_rule_bar_defaults_above_the_code_bar():