Handling Text Matching in GitHub Issue & PR Search for "View on Github"

During a recent review in #414, I discovered that GitHub’s search functionality matches whole words rather than partial matches. This means that searching for `add` will not match `adding`, which completely differs from our search behavior in WATcher. This discrepancy makes it hard for the one-to-one matching of our view on Github feature.

### **Observed Behavior**
- GitHub’s issue and PR search only matches **whole words**.
- `in:title:` or `intitle:` does not enable partial word matching.
- This differs from WATcher’s search behavior, which allows partial word matching.

### **Implication**
- We currently include the search string in the "View on GitHub" feature, but this does not provide the expected results due to GitHub’s word-based search mechanism.
- Users may not find the expected issues/PRs when searching for partial words.

### **Potential Solutions**
1. **Ignore the search string in "View on GitHub"**
- We could remove the search string from the "view on Github" to avoid misleading results.
2. **Use GitHub’s Global Search (`github.com/search`) instead**
- Based on https://github.com/todogroup/gh-issues/issues/70#issuecomment-1936686416 , GitHub’s global search might support partial matches better than the issue/PR search.
- This would require changing generating search links to the Github global search rather than to the specific repo.
3. **Leave as-is**
- Tell the users that results might differ on Github due to the discrepancy in search behavior.

### **Discussion**
How should we handle text matching in our integration with GitHub search? Should we completely remove the search string from "View on GitHub," or attempt to use GitHub’s global search instead?

Would love to hear everyone’s thoughts on this! @CATcher-org/2425s2

Start by tracing the code that generates the “View on GitHub” search links and compare the current repository issue/PR search behavior with GitHub global search. Review the alternatives in the issue and determine which matching behavior should be supported; done means the chosen link behavior is documented and implemented consistently.

Written by the indexing model from the issue text.