bugfix(status): tighten _has_extract — stop crediting mention-in-backticks

[CryptoJones]

Two issues in status.companyos_status's per-project extract check:

1. Each pattern file was read TWICE per project (once for the
   Source project | \name`form, once for the loose`name``
   fallback). On a CompanyOS with N projects and M patterns that
   made status() do O(N*M) extra reads on every invocation.

2. The loose fallback (f"\{project.name}`" in text) credited any backtick mention as an extract. Concrete failure: pattern Y sourced from project beta has a war story that says "Similar trick once worked on alpha; see that project." status() would then report alpha as having an extract too — even though alpha was never the source. Operators reading the morning dashboard would skip running socrates extract` on alpha because
   the column already shows a check mark, defeating the whole point
   of the third 120x deliverable habit.

Fix:

• Read each pattern file exactly once.
• Match only the canonical Source project | \name`line (with the optional**` bold wrapper to tolerate both render formats).
• Drop the loose backtick fallback.

Tests added (2):

• positive: status reports has_extract=True when a pattern's Source
  project field matches.
• negative regression: pattern Y sourced from beta mentions alpha
  in a war story → alpha.has_extract is False.

149/149 tests pass; ruff + mypy clean.

Self-review caveat: behavior change is observable — projects that previously appeared as 'extracted' purely because another pattern's war story mentioned them will now correctly appear as 'not extracted'. Operators relying on the old (buggy) check mark will notice. That's the intended fix; called out in case it confuses anyone.