fix(test): remove lingering @tdd_expected_fail tags for closed bugs #821 and #932 (#1229)

The @tdd_expected_fail tag was already absent from the tag lines of both
features/tdd_context_tier_runtime.feature (bug #821) and
features/tdd_plan_apply_yes_flag.feature (bug #932). However, the feature
description and step-definition docstring for bug #821 still referenced the
@tdd_expected_fail tag and described the bug as unfixed.

Updated the feature description in tdd_context_tier_runtime.feature and the
module docstring in tdd_context_tier_runtime_steps.py to reflect that bug #821
has been fixed and these tests now serve as permanent regression guards. No
changes were needed for bug #932 as its files had no stale references.

Permanent tags @tdd_issue / @tdd_issue_821 and @tdd_issue / @tdd_issue_932
remain in place per the CONTRIBUTING.md TDD Issue Test Tags convention.

ISSUES CLOSED: #1206

Co-authored-by: Brent E. Edwards <brent.edwards@cleverthis.com>
Co-committed-by: Brent E. Edwards <brent.edwards@cleverthis.com>

features/steps/tdd_context_tier_runtime_steps.py

@@ -4,20 +4,10 @@ These steps exercise ``ContextTierService`` and verify that it automatically
 promotes fragments on repeated access, demotes stale fragments, and evicts
 fragments when the hot tier budget overflows.
 
-On ``master`` (before the fix), ``ContextTierService`` has data models and
-manual ``promote()``/``demote()``/``evict_lru()`` methods but NO automatic
-runtime logic:
-
-- ``get()`` updates ``access_count`` and ``last_accessed`` but never
-  auto-promotes a heavily accessed cold/warm fragment.
-- There is no staleness enforcement: no method inspects ``last_accessed``
-  timestamps and auto-demotes stale hot fragments.
-- ``store()`` does not enforce ``TierBudget.max_tokens_hot``: storing
-  beyond the budget does not trigger automatic LRU eviction.
-
-The assertions in these steps will **fail** until the bug is fixed,
-proving the bug exists.  The ``@tdd_expected_fail`` tag inverts the
-result so CI passes.
+Bug #821 identified that ``ContextTierService`` had data models and manual
+``promote()``/``demote()``/``evict_lru()`` methods but NO automatic runtime
+logic.  The bug has been fixed — these tests now serve as a permanent
+regression guard confirming the runtime logic works correctly.
 """
 
 from __future__ import annotations

features/tdd_context_tier_runtime.feature

@@ -5,20 +5,16 @@ Feature: TDD Issue #821 — context tier service has data models but no runtime
   and evicts fragments based on access patterns, staleness, and budget limits
   So that the bug is captured and will be caught by a regression test
 
-  ContextTierService has well-defined data models for hot/warm/cold tiers
-  (ContextTier, TieredFragment, TierBudget) and manual promote()/demote()/
-  evict_lru() methods, but NO automatic runtime logic:
+  Bug #821 identified that ContextTierService had data models for
+  hot/warm/cold tiers (ContextTier, TieredFragment, TierBudget) and
+  manual promote()/demote()/evict_lru() methods, but NO automatic
+  runtime logic.  The bug has been fixed — ContextTierService now:
 
-  - get() touches access metadata but never auto-promotes a frequently
-    accessed cold/warm fragment to a higher tier.
-  - There is no staleness enforcement: no method checks last_accessed
-    timestamps and demotes stale hot fragments to warm/cold.
-  - store() does not enforce budget limits: storing beyond
-    max_tokens_hot does not trigger automatic eviction.
+  - auto-promotes frequently accessed cold/warm fragments to a higher tier,
+  - enforces staleness by demoting stale hot fragments to warm/cold,
+  - enforces budget limits by evicting on hot tier overflow.
 
-  These tests assert the expected runtime behaviour and will FAIL until
-  the bug is fixed.  The @tdd_expected_fail tag inverts the result so
-  CI passes.
+  These tests serve as a permanent regression guard for the fix.
 
   Scenario: Promotion on repeated access moves fragment to a higher tier
     Given a context tier service with default budget