fix: only relabel whitelisted 5'Flank mutations as "Promoter" with custom filters (#65)

[officialasishkumar]

Summary

MutationFilter.acceptMutation() relabels 5'Flank mutations' protein change to "Promoter" inconsistently, depending on whether a custom filtered-mutations list (sequenced_samples/variant_classification_filter in the meta file) is supplied:

Path	Whitelisted gene (e.g. TERT)	Other gene
Default filter (no custom list)	relabeled "Promoter", accepted	rejected
Custom filter (before this PR)	relabeled "Promoter", accepted	relabeled "Promoter", accepted

So the exact same 5'Flank mutation on a non-whitelisted gene is labeled "Promoter" or not purely based on the filter configuration. The "Promoter" convention is specific to whitelisted promoter genes (currently only TERT, Entrez 7015), so labeling arbitrary genes' 5'Flank mutations as promoter mutations misrepresents them. This was reported in #65 as an unintended asymmetry.

Changes

src/main/java/org/mskcc/cbio/portal/scripts/MutationFilter.java: in the custom-filter branch, gate the "Promoter" relabeling by the promoter whitelist, exactly as the default-filter branch already does:

if (safeStringTest(mutation.getMutationType(), "5'Flank")
        && whiteListGenesForPromoterMutations.contains(mutation.getEntrezGeneId())) {
    mutation.setProteinChange("Promoter");
}

The accept/reject contract of custom filters is intentionally unchanged: a 5'Flank type that is not in the custom list is still accepted (a custom list only excludes the types it names); it is simply no longer relabeled "Promoter" unless its gene is whitelisted.

Tests

Added TestMutationFilterPromoter, a focused unit test (the filtering logic is self-contained and does not touch the database) covering both filter modes for whitelisted (TERT) and non-whitelisted genes:

mvn -Dtest=TestMutationFilterPromoter test
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

The existing TestMutationFilter only exercises the default filter path and is unaffected.

Fixes #65